Descritores máximos práticos de arquivos abertos (ulimit -n) para um sistema de alto volume

Recentemente, começamos a testar nosso aplicativo de carregamento e percebemos 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 Discos rígidos SATA de 2,5 "

Eu verifiquei o limite do descritor de arquivo e foi definido como 1024. Considerando que nosso aplicativo pode ter potencialmente cerca de 1.000 conexões de entrada e 1000 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 conhecer quaisquer 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 teoricamente abrir?

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 definimos 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).

Definindo ulimit:

# ulimit -n 99999

Arquivos max sysctl:

#sysctl -w fs.file-max=100000

Além disso, e muito importante, pode ser necessário verificar se o seu aplicativo tem um vazamento de descritor de memória / arquivo. Use lsof para ver tudo o que está aberto para ver se eles são válidos ou não. Não tente alterar seu sistema para solucionar os erros dos aplicativos.

Você sempre pode apenas

cat /proc/sys/fs/file-nr

Durante a situação de 'alta carga', para ver quantos descritores de arquivo estão em uso.

Quanto ao máximo - depende apenas 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; essa memória não será trocá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 ele usará e / ou testará.

Executamos servidores de banco de dados com ~ 10k descritores de arquivo abertos (principalmente em arquivos de disco reais) sem grandes problemas, mas eles são de 64 bits e possuem grande quantidade de memória RAM.

A configuração ulimit é por processo, mas também existe um limite para todo o sistema (32k por padrão)

Não conheço pessoalmente as melhores práticas. É um pouco subjetivo, dependendo da função do sistema.

Lembre-se de que o 1024 que você vê é um limite por usuário e não um limite para todo o sistema. Considere quantos aplicativos você executa neste sistema. Este é o único? O usuário que executa esse aplicativo está fazendo outra coisa? (IE, você tem humanos usando essa conta para fazer login e executar scripts que podem potencialmente fugir?)

Dado que a caixa está executando apenas esse 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 interna de desenvolvimento, eu pediria a opinião deles. Se for de um fornecedor terceirizado, eles podem ter requisitos ou recomendações específicas.

Parece-me uma dessas 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. Seu limite na época também era 1024, então estou um pouco surpreso ao ver que agora é o mesmo para Linux, parece que deveria ser maior.

Encontrei o seguinte link como 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