linux - para - jboss demasiados ficheros abiertos

ubuntu: ¿hay demasiados archivos abiertos? (8)

¿Puede establecer el límite en el Servicio de esta manera?

add: LimitNOFILE=65536 en: /etc/systemd/system/{NameofService}.service

Tengo un servicio websocket. es extraño que tenga un error: "demasiados archivos abiertos", pero configuré el sistema:

/etc/security/limits.conf * soft nofile 65000 * hard nofile 65000 /etc/sysctl.conf net.ipv4.ip_local_port_range = 1024 65000 ulimit -n //output 6500

Así que creo que mi sistema se configura correctamente.

Mi servicio es administrado por un supervisor, ¿es posible que los límites del supervisor?

proceso de verificación inicia por supervisor:

cat /proc/815/limits Max open files 1024 4096 files

inicio manual del proceso de verificación:

cat /proc/900/limits Max open files 65000 65000 files

El motivo es el supervisor de administración de servicios utilizado. si reinicio el supervisor y reinicio el proceso hijo, es "max open files" ok (65000) pero erróneo (1024) cuando el reinicio del supervisor del sistema se inicia automáticamente.

¿Puede ser que el nivel de inicio del supervisor es demasiado alto y la configuración del sistema no funciona cuando el supervisor comienza?

editar:

sistema: ubuntu 12.04 64bit

No es un problema de supervisor, todos los procesos de inicio automático después del reinicio del sistema no utilizan la configuración del sistema (max open files = 1024), pero reiniciar está correcto.

actualizar

Tal vez el problema es:

Ahora la pregunta es cómo establecer un límite nofile global porque no quiero establecer el límite de nofile en cada script upstart que necesito.

Creo que esto no tiene nada que ver con los archivos abiertos (es un mensaje de error simplemente erróneo). Cualquier puerto que use su aplicación en uso. 1. Intenta encontrar la ID del proceso con el comando

ps aux

2. Mata el proceso (por ejemplo 8572) con el comando

sudo kill -9 8572

3. Comience su aplicación nuevamente.

Intenta editar /etc/sysctl.conf y ajusta los límites globalmente Por ejemplo:

Fuerza el límite a 100000 archivos.

vi /etc/sysctl.conf

Adjuntar:

fs.file-max = 100000

Guarde y cierre el archivo. Los usuarios deben desconectarse y volver a iniciar sesión para que los cambios entren en vigor o simplemente escribir el siguiente comando:

sysctl -p

La respuesta de luqmaan fue el boleto para mí, excepto por una pequeña advertencia: el * comodín no se aplica a la raíz en Ubuntu (como se describe en los comentarios de limits.conf ).

Debe establecer explícitamente el límite para root si supervisord se inicia como el usuario raíz:

vi /etc/security/limits.conf

root soft nofile 65535 root hard nofile 65535

Para cualquier googlers cansado: es posible que esté buscando la configuración de minfds en la configuración de supervisor . Esta configuración parece tener efecto tanto para el proceso de supervisión como para los niños. Tenía una serie de otras estrategias, incluido el lanzamiento de un script de shell que establece los límites antes de ejecutar el programa real, pero esto fue lo único que funcionó.

Puedes encontrar tu límite con:

cat /proc/sys/fs/file-max

o sysctl -a | grep file sysctl -a | grep file

cámbielo en el archivo / proc / sys / fs / file-max o con:

sysctl -w fs.file-max=100000

Se corrigió este problema al establecer los límites para todos los usuarios en el archivo:

$ cat /etc/security/limits.d/custom.conf * hard nofile 550000 * soft nofile 550000

REINICIE EL SERVIDOR después de establecer los límites.

MUY IMPORTANTE: la carpeta /etc/security/limits.d/ contiene límites específicos del usuario. En mi caso, los límites relacionados con hadoop 2 (cloudera). Estos límites específicos del usuario anularían los límites globales, por lo que si no se aplican sus límites, asegúrese de verificar los límites específicos del usuario en la carpeta /etc/security/limits.d/ y en el archivo /etc/security/limits.conf .

PRECAUCIÓN: Establecer los límites específicos del usuario es el camino a seguir en todos los casos. Se debe evitar establecer el límite global (*). En mi caso, era un entorno aislado y solo necesitaba eliminar el problema de límites de archivos de mi experimento.

Espero que esto le ahorre algo de pelo a alguien, ¡ya que pasé demasiado tiempo tirando de mi pelo pedazo a pedazo!

Yo tuve el mismo problema. Aunque ulimit -Sn muestra mi nuevo límite, ejecutar supervisorctl restart all y buscar los archivos de proc no mostró los nuevos límites.

El problema es que el supervisord todavía tiene los límites originales. Por lo tanto, cualquier proceso secundario que cree tendrá los límites originales.

Entonces, la solución es matar y reiniciar el supervisord .