Recentemente, começamos o teste de carga de nosso aplicativo e notamos que ele ficou sem descritores de arquivo após cerca de 24 horas.
Estamos executando o RHEL 5 em um Dell 1955:
CPU: 2 x Dual Core 2.66GHz 4MB 5150 / 1333FSB RAM: 8GB RAM HDD: 2 x 160GB 2.5" discos rígidos SATA
Verifiquei o limite do descritor de arquivo e ele foi definido em 1024. Considerando que nosso aplicativo poderia ter cerca de 1.000 conexões de entrada, bem como 1.000 conexões de saída, isso parece bastante baixo. Sem mencionar os arquivos reais que precisam ser abertos.
Meu primeiro pensamento foi apenas aumentar o parâmetro ulimit -n em algumas ordens de magnitude e, em seguida, executar novamente o teste, mas eu queria saber as possíveis ramificações de definir essa variável muito alta.
Existem práticas recomendadas para definir isso além de descobrir quantos descritores de arquivo nosso software pode abrir teoricamente?
Esses limites vieram de uma época em que vários usuários "normais" (não aplicativos) compartilhavam o servidor e precisávamos de maneiras de protegê-los do uso de muitos recursos.
Eles são muito baixos para servidores de alto desempenho e geralmente os configuramos para um número muito alto. (24k ou mais) Se você precisar de números mais altos, também precisará alterar a opção sysctl file-max (geralmente limitada a 40k no Ubuntu e 70k no rhel).
Configurando ulimit:
Arquivos sysctl max:
Além disso, e muito importante, você pode precisar verificar se seu aplicativo tem um vazamento de descritor de memória/arquivo. Use lsof para ver tudo o que está aberto para ver se são válidos ou não. Não tente alterar seu sistema para contornar bugs de aplicativos.
Você sempre poderia apenas
Durante a situação de 'carga alta' para ver quantos descritores de arquivo estão em uso.
Quanto ao máximo - só depende do que você está fazendo.
Se os descritores de arquivo forem soquetes tcp, etc, você corre o risco de usar uma grande quantidade de memória para os buffers de soquete e outros objetos do kernel; esta memória não será intercambiável.
Mas caso contrário, não, em princípio, não deve haver problema. Consulte a documentação do kernel para tentar descobrir quanta memória do kernel ele usará e/ou testá-lo.
Executamos servidores de banco de dados com ~ 10k descritores de arquivo abertos (principalmente em arquivos de disco real) sem um grande problema, mas eles são de 64 bits e têm muita memória ram.
A configuração ulimit é por processo, mas também há um limite em todo o sistema (32k, acho que por padrão)
Eu pessoalmente não estou ciente de quaisquer práticas recomendadas. É um pouco subjetivo, dependendo da função do sistema.
Lembre-se de que 1024 que você está vendo é um limite por usuário e não um limite de todo o sistema. Considere quantos aplicativos você executa neste sistema. Este é o único? O usuário que executa este aplicativo está fazendo mais alguma coisa? (IE você tem humanos usando esta conta para fazer login e executar scripts que podem potencialmente fugir?)
Dado que a caixa está executando apenas este aplicativo e a conta que executa esse aplicativo é apenas para esse fim, não vejo mal em aumentar seu limite como você sugere. Se for uma equipe de desenvolvimento interna, eu pediria a opinião deles. Se for de um fornecedor terceirizado, eles podem ter requisitos ou recomendações específicas.
Esta me parece uma daquelas perguntas melhor respondidas com "teste em um ambiente de desenvolvimento". Lembro-me de anos atrás Sun ficou nervoso quando você mexeu com isso, mas não tão nervoso. O limite na época também era 1024, então estou um pouco surpreso ao ver que é o mesmo agora para o Linux, parece que deveria ser maior.
Achei o link a seguir educacional quando pesquisei respostas para sua pergunta: http://www.netadmintools.com/art295.html
E este também: https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible