Comprender los descriptores de archivos max para linux y nginx, y el mejor valor para worker_rlimit_nofile

Obtuve el error aparentemente común "demasiados descriptores de archivo" en nginx. Después de mucha búsqueda, la solución es claramente aumentar el número de descriptores de archivo disponibles para nginx. Pero no hay suficiente información para que me sienta cómodo haciendo esto de una manera significativa y segura. Estos son los puntos principales que cubren la mayoría de los foros / correos electrónicos:

• el sistema operativo tiene su propio límite de descriptor de archivo total (en mi sistema, cat /proc/sys/fs/file-maxsalidas "100678")
• cada usuario también puede tener su propio límite (pero en mi sistema, al ejecutarse ulimitcomo cualquier usuario emite "ilimitado", vea la actualización en la parte inferior con más detalles )
• algunas personas dijeron algo similar a lo que dijo esta persona : 'Directiva trabajador_nombre_del_archivo no especifica "cuántos", es el límite del sistema operativo el que lo hace. La directiva obrero_limit_nofile solo permite una manera rápida y sucia de ampliar este límite si no es suficiente. Entonces, ¿supongo que la implicación es que es "mejor" establecer el límite para el usuario de nginx OS en lugar de en la configuración?

Simplemente puedo agregar un valor de trabajador_rlimit_nofile mayor que el número de conexiones por trabajador y llamarlo por día, pero siento que realmente no sé qué está pasando aquí.

• ¿Por qué el límite por trabajador sería menor que el límite del sistema operativo?
• ¿Cómo puedo saber cuál es mi límite ahora?

actualización : tanto para el usuario root como para el usuario normal, las salidas ulimit son "ilimitadas", PERO ulimit -Hny ulimit -Snambas generan 1024

worker_rlimit_nofileestablecerá el límite para los descriptores de archivo para los procesos de trabajo en oposición al usuario que ejecuta nginx. Si otros programas que se ejecutan con este usuario no podrán manejar con gracia la ejecución de los descriptores de archivos, entonces debe establecer este límite un poco menos de lo que es para el usuario.

Primero, ¿qué está usando sus descriptores de archivo?

1. Cada conexión activa a un cliente
2. ¿Usando proxy_pass? Eso abrirá un socket al host: el puerto que maneja estas solicitudes
3. ¿Usando proxy_pass a un puerto local? Esa es otra toma abierta. (Para el propietario de ese proceso)
4. nginx sirve archivos estáticos

¿Por qué el límite por trabajador sería menor que el límite del sistema operativo?

El sistema operativo controla esto porque el trabajador no es el único proceso que se ejecuta en la máquina. Para cambiarlo para el usuario que ejecuta nginx, consulte a continuación. Sería muy malo si sus trabajadores usaran todos los descriptores de archivo disponibles para todos los procesos, no establezca sus límites para que sea posible.

#/etc/sysctl.conf
#This sets the value you see when running cat  /proc/sys/fs/file-max
fs.file-max = 65536"


#/etc/security/limits.conf
#this sets the defaults for all users
* soft nofile 4096
* hard nofile 4096

#This overrides the default for user `usernamehere`
usernamehere soft nofile 10240
usernamehere hard nofile 10240

Después de esos cambios en el límite de seguridad, creo que aún tenía que aumentar el límite suave para el usuario que lo usa ulimit.

¿Cómo puedo saber cuál es mi límite ahora?

ulimit -a Mostrará todos los límites asociados con el usuario con el que lo ejecuta.

Hay que verificar la fuente para ser sincero, pero es bastante bajo.

Utilicé worker_rlimit_nofile 15000;y no tuve problemas, puede aumentarlo de forma segura, sin embargo, la posibilidad de quedarse sin descriptores de archivo es minúscula.