Defina o valor agradável padrão para um determinado usuário (limits.conf)

Alguém poderia me dizer como definir o valor padrão de nice(como exibido por top) de um usuário? Eu descobri que /etc/security/limits.conf é o local, mas se eu colocar:

username_of_a_guy  -  nice  19
username_of_a_guy  soft  nice  19
username_of_a_guy  hard  nice  19

Não funciona (enquanto deveria, certo?).

Observe que eu reiniciei desde então.

Muito obrigado antecipadamente por qualquer ajuda. Estou usando o debian unstable (uptodate).

Contexto:

No meu trabalho, temos uma rede local: todo mundo tem seu próprio computador e todos podem criar uma conta na máquina de outra pessoa, se quiserem. A regra geral é simplesmente que, se você trabalha em outro computador, agrade seus processos ( nice 19).

Gostaria de definir o valor legal padrão de um determinado usuário para 19 de uma vez por todas.

— Alex
fonte

Um pouco relacionado: unix.stackexchange.com/questions/209398/…

— Kusalananda

Respostas:

Eu acredito que o formato correto é:

@users      -       priority        10
username    -       priority        19

Este é um exemplo das configurações que estou usando na produção (obviamente com usuários / grupos reais).

A niceconfiguração é determinar o valor mínimo agradável (ou seja, prioridade máxima) que alguém pode definir seu processo, e não a prioridade padrão.

— jsbillings
fonte

Antes de tudo, obrigado pela resposta (obrigado também, @mattdm). Parece que esse método funciona. No entanto, ainda estou confuso sobre a diferença entre "legal" e "prioritário": ambos são exibidos por "superior", mas o valor citado para legal é o que tenho que definir como prioridade. Parece um pouco estranho para mim. Além disso, uma prioridade maior (digamos 39 em vez de 20) significa um processo menos importante, assim como bom? Obrigado.

— 1128 Alex

A boa prioridade 'NI' no topo é o que seria definido pela priorityconfiguração de limites . Essa será a prioridade padrão de qualquer processo para esse usuário / grupo quando eles efetuarem login. Você só pode definir isso entre -20 e 20. O valor 'PR' no topo é a prioridade real do planejador, que é determinada por vários fatores pelo agendador do kernel.

— jsbillings

Além disso, sim, uma prioridade mais alta significa que é menos provável que seja agendado para obter ciclos de CPU.

— jsbillings

Ok, muito obrigado por essa desambiguação. BTW, eu não tentei os outros métodos (envolvendo andou cgroup) que podem ser melhores em outras situações que a minha (necessidade de uma verificação contínua ou gerenciamento de muitos usuários - o que é um pouco demais no meu caso).

— 1128 Alex

Hmmmm ... Isso funcionou para um usuário, mas não para o outro na minha máquina Ubuntu. Eu voltarei se eu puder descobrir o porquê. ;-)

— Ken Sharp

Posso confirmar que isso também não funciona no meu sistema. Os documentos dizem "kernel 2.6.11 and up", e eu estou no Fedora rawhide com o kernel 2.6.38-rc6. Gostaria de saber se é dependente do agendador e não funciona com o CFQ introduzido no 2.6.23 ("Completely Fair Scheduler").

Algo que funcionará, no entanto, é o impossível de procurar por causa de seu nome horrível and- o daemon auto-agradável. Veja http://and.sourceforge.net/ . Está disponível no Fedora com yum install and, mas infelizmente não parece estar no EPEL. E é no Debian também: apt-get install and.

Se você estiver usando uma distribuição moderna, há uma maneira ainda melhor. Você pode usar as ferramentas do libcgroup para configurar um cgroup no nível do kernel que limita os compartilhamentos de CPU e "classificar" automaticamente os processos desse usuário nesse cgroup. Com isso, você também pode priorizar a E / S e limitar o uso da memória (incluindo o compartilhamento do cache do disco).

— mattdm
fonte

Concordo que o uso do cgroups é uma excelente maneira de impedir que outras pessoas sequestrem todos os ciclos da CPU no seu computador. Infelizmente, os sistemas que eu suporte (RHEL5) não têm kernels que o suportam, então eu tenho que continuar ajustando a prioridade. Depois de atualizar para o RHEL6, tenho certeza de que teremos algumas configurações bastante complexas dos cgroups.

— jsbillings