Descriptores prácticos de archivos abiertos máximos (ulimit -n) para un sistema de gran volumen

Recientemente comenzamos a probar la carga de nuestra aplicación y notamos que se quedó sin descriptores de archivo después de aproximadamente 24 horas.

Estamos ejecutando RHEL 5 en un Dell 1955:

CPU: 2 x Dual Core 2.66GHz 4MB 5150 / 1333FSB RAM: 8GB RAM HDD: 2 x 160GB Discos duros SATA de 2.5 "

Verifiqué el límite del descriptor de archivo y se estableció en 1024. Teniendo en cuenta que nuestra aplicación podría tener aproximadamente 1000 conexiones entrantes, así como 1000 conexiones salientes, esto parece bastante bajo. Sin mencionar los archivos reales que deben abrirse.

Lo primero que pensé fue aumentar el parámetro ulimit -n en unos pocos órdenes de magnitud y luego volver a ejecutar la prueba, pero quería saber cualquier ramificación potencial de establecer esta variable demasiado alta.

¿Existe alguna práctica recomendada para configurar esto que no sea calcular cuántos descriptores de archivo puede abrir nuestro software en teoría?

Estos límites provienen de una época en la que múltiples usuarios "normales" (no aplicaciones) compartirían el servidor, y necesitábamos formas de protegerlos del uso de demasiados recursos.

Son muy bajos para servidores de alto rendimiento y generalmente los configuramos en un número muy alto. (24k más o menos) Si necesita números más altos, también necesita cambiar la opción sysctl file-max (generalmente limitada a 40k en ubuntu y 70k en rhel).

Configuración de ulimit:

# ulimit -n 99999

Archivos max de Sysctl:

#sysctl -w fs.file-max=100000

Además, y muy importante, es posible que deba verificar si su aplicación tiene una fuga de descriptor de memoria / archivo. Use lsof para ver todo lo que tiene abierto para ver si son válidos o no. No intente cambiar su sistema para evitar errores de aplicaciones.

Siempre podrías

cat /proc/sys/fs/file-nr

Durante la situación de 'carga alta' para ver cuántos descriptores de archivo están en uso.

En cuanto al máximo, solo depende de lo que esté haciendo.

Si los descriptores de archivo son sockets tcp, etc., entonces corre el riesgo de utilizar una gran cantidad de memoria para los buffers de sockets y otros objetos del núcleo; esta memoria no será intercambiable.

Pero por lo demás, no, en principio no debería haber ningún problema. Consulte la documentación del kernel para tratar de calcular cuánta memoria del kernel usará y / o probar.

Ejecutamos servidores de bases de datos con ~ 10k descriptores de archivo abiertos (principalmente en archivos de disco reales) sin un problema importante, pero son de 64 bits y tienen un montón de ram.

La configuración ulimit es por proceso, pero también hay un límite en todo el sistema (32k creo que por defecto)

No conozco personalmente ninguna de las mejores prácticas. Es algo subjetivo dependiendo de la función del sistema.

Recuerde que 1024 que está viendo es un límite por usuario y no un límite de todo el sistema. Considere cuántas aplicaciones ejecuta en este sistema. ¿Es este el único? ¿El usuario que ejecuta esta aplicación está haciendo algo más? (Es decir, ¿tiene seres humanos que usan esta cuenta para iniciar sesión y ejecutar scripts que posiblemente se escapen?)

Dado que el cuadro solo ejecuta esta aplicación y la cuenta que ejecuta dicha aplicación es solo para ese propósito, no veo ningún daño en aumentar su límite como usted sugiere. Si se trata de un equipo de desarrollo interno, pediría su opinión. Si es de un proveedor externo, pueden tener requisitos o recomendaciones específicos.

Esta me parece una de esas preguntas mejor respondidas con "probarlo en un entorno de desarrollo". Recuerdo que hace años Sun se puso nervioso cuando te metiste con esto, pero no tanto. Su límite en ese momento también era 1024, así que estoy un poco sorprendido de ver que ahora es lo mismo para Linux, parece que debería ser más alto.

Encontré el siguiente enlace educativo cuando busqué en Google las respuestas a su pregunta: http://www.netadmintools.com/art295.html

Y este también: https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible