Establecer un valor agradable predeterminado para un usuario determinado (limits.conf)

12

¿Podría alguien decirme cómo establecer el valor predeterminado de nice(como se muestra por top) de un usuario? He encontrado que /etc/security/limits.conf es el lugar, pero si pongo cualquiera:

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

No funciona (aunque debería, ¿verdad?).

Tenga en cuenta que he reiniciado desde entonces.

Gracias mucho por adelantado por cualquier ayuda. Estoy usando debian inestable (uptodate).

Contexto:

En mi trabajo, tenemos una red local: todos tienen su propia computadora y todos pueden crear una cuenta en la máquina de otra persona si a uno le gusta. La regla general es simplemente que si trabajas en otra computadora, por favor, mejora tus procesos ( nice 19).

Me gustaría establecer el valor agradable predeterminado para un usuario determinado en 19 de una vez por todas.

login nice limit Alex
fuente
Algo relacionado: unix.stackexchange.com/questions/209398/…
Kusalananda

Respuestas:

13

Creo que el formato correcto es:

@users      -       priority        10
username    -       priority        19

Este es un ejemplo de la configuración que estoy usando en producción (obviamente con usuarios / grupos reales).

La niceconfiguración es determinar el valor mínimo agradable (es decir, la prioridad máxima) a quien alguien puede configurar su proceso, no su prioridad predeterminada.

jsbillings
fuente
2
En primer lugar, gracias por su respuesta (gracias también, @mattdm). Parece que este método funciona. Sin embargo, todavía estoy confundido acerca de la diferencia entre "agradable" y "prioridad": ambos se muestran en "superior", pero el valor citado para agradable es el que tengo que establecer como prioridad. Me parece un poco extraño. Además, ¿una mayor prioridad (digamos 39 en lugar de 20) significa un proceso menos importante como lo es para bien? Gracias.
Alex
44
La buena prioridad de 'NI' en la parte superior es lo que establecería la priorityconfiguración de límites . Esta será la prioridad predeterminada de cualquier proceso para ese usuario / grupo cuando inicien sesión. Solo puede establecer esto entre -20 y 20. El valor 'PR' en la parte superior es la prioridad real del planificador, que está determinada por varios factores por el planificador del núcleo.
jsbillings
1
Además, sí, una prioridad más alta significa que es menos probable que se programe para obtener ciclos de CPU.
jsbillings
1
Ok, muchas gracias por esta desambiguación. Por cierto, no he probado los otros métodos (que involucran ando cgroup) que podrían ser mejores en otras situaciones que la mía (necesidad de una verificación continua o administración de muchos usuarios, lo cual es demasiado en mi caso).
Alex
Hmmmm ... Esto funcionó para un usuario pero no para el otro en mi máquina Ubuntu. Volveré si puedo averiguar por qué. ;-)
Ken Sharp
3

Puedo confirmar que eso tampoco funciona en mi sistema. Los documentos dicen "kernel 2.6.11 y superior", y estoy en Fedora rawhide con kernel 2.6.38-rc6. Me pregunto si depende del planificador y no funciona con el CFQ introducido en 2.6.23 ("Planificador completamente justo").

Sin embargo, algo que funcionará es el imposible de buscar por su horrible nombre and: el demonio auto-agradable. Ver http://and.sourceforge.net/ . Esto está disponible en Fedora con yum install and, pero desafortunadamente no parece estar en EPEL. Y es también en Debian: apt-get install and.

Sin embargo, si está utilizando una distribución moderna, hay una forma aún mejor. Puede usar las herramientas de libcgroup para configurar un cgroup a nivel de kernel que limite los recursos compartidos de la CPU y para "clasificar" automáticamente los procesos de ese usuario en este cgroup. Con esto, también puede priorizar las E / S y limitar el uso de memoria (incluido el uso compartido de la memoria caché del disco).

mattdm
fuente
Estoy de acuerdo en que usar cgroups es una excelente manera de limitar que otras personas acaparen todos los ciclos de CPU en su computadora. Lamentablemente, los sistemas que apoyo (RHEL5) no tienen núcleos que lo admitan, por lo que tengo que seguir ajustando la prioridad. Una vez que actualizamos a RHEL6, estoy seguro de que tendremos algunas configuraciones de cgroups bastante complejas.
jsbillings