Nossos sistemas baseados em nuvem usam Java e exigem mais de 1024 para o limite máximo de descritor de arquivo. Em um de nossos sistemas virtuais, toda vez que tentamos fazer essa alteração, eu posso fazer com que ela mude e ela será persistente na primeira reinicialização (não testei vários), mas se pararmos e iniciarmos nosso aplicativo java, o limite parece ser redefinido para 1024.
Informações do sistema:
Linux mx.xen16.node01002 3.1.0-1.2-xen # 1 SMP Qui 3 de novembro 14:45:45 UTC 2011 (187dde0) x86_64 GNU / Linux
Aqui estão os passos que eu dei:
editado /etc/sysctl.conf e acrescentado fs.file-max = 4096
Antes de aplicar, verifique o limite do processo (PID 1530):
raiz 1530 6,7 31,0 1351472 165244 pts / 0 Sl 17:12 0:58 java
cat / proc / 1530 / limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes unlimited unlimited processes
Max open files 1024 1024 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 16382 16382 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Agora aplico a alteração com:
sudo sysctl -p
fs.file-max = 4096 (ok, deve ser definido)
Eu agora faço um reboot
Quando o sistema volta a funcionar, o aplicativo java é iniciado automaticamente e, usando o novo PID, eu verifico os limites novamente.
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 3818 3818 processes
Max open files 4096 4096 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 3818 3818 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
O limite está definido corretamente, no entanto, se eu iniciar e parar o aplicativo java, o limite será padronizado de volta para 1024. Não há um problema com o aplicativo java. Este é um dos vários sistemas baseados em nuvem idênticos em todo o mundo, cada um deles uma cópia deste. Essa VM reside na Gigatux. Temos vários outros sistemas idênticos no Giga executando o mesmo sistema operacional, mesma versão e o mesmo aplicativo e versão do aplicativo. Apenas este está se comportando de maneira estranha. Por favor ajude.
* UPDATE *
Eu removi a declaração do final do sysctl.conf por recomendação de David. Se eu emitir ulimit -n, o limite é de fato configurado para 4092. Se eu olhar em /etc/security/limits.conf, você pode ver os limites configurados aqui também.
* hard nofile 4096
* soft nofile 4096
No entanto, se eu reiniciar o processo java, ele ainda retorna para 1024.
agent@mx:~$ cat /proc/2432/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes unlimited unlimited processes
Max open files 1024 1024 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 16382 16382 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
agent@mx:~$ echo -n $SHELL ' ' && ulimit -n
/bin/bash 4096
* UPDATE *
Ok, acho que isso pode ser corrigido. Eu mudei o seguinte:
* hard nofile 4096
* soft nofile 4096
de volta para o seguinte:
root hard nofile 4096
root soft nofile 4096
e o problema parece estar resolvido