¿Cómo difieren ulimit -n y / proc / sys / fs / file-max?


32

Noté que en una nueva imagen CentOS que acabo de arrancar desde EC2, el valor predeterminado de ulimit es 1024 archivos abiertos, pero / proc / sys / fs / file-max está configurado en 761,408 y me pregunto cómo funcionan estos dos límites juntos. Supongo que ulimit -n es un límite por usuario de número de descriptores de archivo, mientras que / proc / sys / fs / file-max es para todo el sistema. Si ese es el caso, supongamos que he iniciado sesión dos veces como el mismo usuario: ¿cada usuario conectado tiene un límite de 1024 en el número de archivos abiertos, o es un límite de 1024 archivos abiertos combinados entre cada uno de los registrados? en los usuarios?

¿Y tiene un gran impacto en el rendimiento configurar sus descriptores de archivos máximos en un número muy alto, si su sistema nunca abre muchos archivos?


Etiquetas agregadas: bash linux kernel system-resources
Warner

Respuestas:


28

file-maxes el descriptor de archivo máximo (FD) impuesto a nivel de núcleo, que no puede ser superado por todos los procesos sin aumentar. losulimit se aplica a nivel de proceso, que puede ser menor que el file-max.

No hay riesgo de impacto en el rendimiento al aumentar file-max . Las distribuciones modernas tienen el FD máximo establecido bastante alto, mientras que en el pasado requería la recompilación y modificación del kernel para aumentar más allá de 1024. No aumentaría todo el sistema a menos que tenga una necesidad técnica.

La configuración por proceso a menudo necesita ajustarse para servir a un demonio en particular, ya sea una base de datos o un servidor web. Si elimina el límite por completo, ese demonio podría agotar todos los recursos disponibles del sistema; lo que significa que no podrá solucionar el problema, excepto presionando el botón de reinicio o el ciclo de encendido. Por supuesto, es probable que cualquiera de esos resultados dañe los archivos abiertos.


¿Tengo entendido que los límites por usuario establecidos con ulimit son los mismos para todos los usuarios? ¿Hay alguna manera de usar diferentes valores por usuario o no?
Oliver

Sí, la configuración se puede establecer de forma global y por usuario.
Warner

Si recibo tu publicación correctamente, esto no es cierto. Es por proceso generado por el usuario xy, y esto está limitado por el sistema de archivos máximo definido en /etc/sysctl.conf
Jeredepp

3
¡El ulimitlímite no es por usuario, sino por proceso! Ver unix.stackexchange.com/questions/55319/…
Tonin

@Tonin: Sí, esta respuesta es incorrecta.
Nemo

11

La limitación de ulimit es por usuario único. Por lo tanto, user1, independientemente de cuántas veces haya iniciado sesión o esté ejecutando procesos, se limitaría a 1024. Se combina.

No estoy seguro si entiendo completamente el significado de esa oración (el inglés no es mi lengua materna) Si esa oración significa que la configuración ulimit para los descriptores de archivos no es una limitación por proceso, la respuesta aceptada (AFAIK) es incorrecta.

Lo que quiero decir es que si algún usuario ha lanzado 4 procesos y la configuración ulimit para FD es 1024, cada proceso puede abrir 1024 FD. El usuario no se limitará a 1024 FD sino a los procesos que inicia ese usuario.

Por ejemplo:

me@superme:~$ ulimit -n
1024
me@superme:~$ lsof | grep $USER | wc -l
8145

Aquí un ejemplo de perl donde alcanzamos el límite (es un límite por proceso):

#!/usr/bin/perl

$count = 0;
@filedescriptors;

while ($count <= 1024) {
    $FILE = ${count};
    open $FILE, ">", "/tmp/example$count" or die "\n\n FDs: $count $!";
    push(@filedescriptors, $FILE);
    $count ++;
}

Resultado:

FDs: 1021 Too many open files at ./test.pl line 8.

1021 porque había 3 descriptores de archivos abiertos antes de llegar al ciclo while (stdout, stdin y stderr)

Lo siento si estoy completamente equivocado o si entendí mal la respuesta.


Entonces tienes razón. La respuesta de @ Warner es incorrecta en este sentido porque el límite es por proceso y no por usuario
filipenf
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.