Hoje meu servidor travou com Too many open files in system:, mas eu já tem valores altos, qual é o valor máximo para isso?

Eu sinto que não há bons resultados no Google para isso, explicando o que precisa ser levado em consideração para definir esses valores, eles apenas dizem para definir como 100k.

Eu tenho um servidor de 32 GB de RAM usando apenas 10 GB agora, suponho que aumentar os limites do arquivo para valores muito altos aumentará o uso de RAM. Existe algum tipo de fórmula que você pode usar para calcular isso? Como para 8 GB de RAM, você pode ter um número X de arquivos abertos?

Configurações atuais: 

cat /proc/sys/fs/file-max 100000 ulimit -Hn 1048576 ulimit -Sn 1024

Comentários

  • Não é uma resposta, mas me parece que limitar o número máximo de arquivos abertos não é uma forma de economizar RAM, mas o desempenho de E / S do disco. Permitir um grande número de arquivos abertos implica permitir um (potencialmente) grande número de arquivos simultâneos acesso ao disco. Além disso, você provavelmente tem um limite geral para todo o sistema, bem como um limite por processo nisso. Não sendo um usuário Linux, não posso ' dizer muito mais sobre que, diferente de ulimit mostrará / definirá um limite de recursos por processo.
  • isso é mesmo uma preocupação para discos SSD? Ele ' é um servidor e eu não ' não me importo se ele morrer, a empresa de hospedagem irá apenas substituí-lo e eu tenho backups. Também li que os sockets de rede também podem causar esse problema, eu me preocupo principalmente com o desempenho. Eu ' estou pagando pelo hardware se usar 100% ou 5%, desde que ' esteja melhorando o desempenho, por que me importar? Para um servidor em nuvem, eu poderia ver isso como um problema, mas para hardware dedicado, não
  • Sim, o número de soquetes abertos também contará para este limite (descritores de arquivo abertos em geral). Eu esqueci disso. Portanto, se a RAM é sua única preocupação, não ' acho que me preocuparia em aumentar o limite, a menos que isso signifique que qualquer serviço que você fornecer comece a alocar memória extra relacionada a cada socket aberto. Isso seria algo que só você poderia investigar.

Resposta

Como Kusalananda diz, aumentando file-max não terá um impacto direto no uso da memória, mas permitirá que os processos abram mais descritores de arquivo, o que terá um efeito indireto (tanto de rastreamento de descrições de arquivo no kernel quanto de aumento de memória uso nos processos que usam essas descrições e descritores) – os comentários do kernel sugerem aproximadamente um kilobyte por arquivo para os dados do kernel e irão reduzir o valor padrão de file-max (8192) se isso acabar representa mais de 10% da memória quando o sistema inicializa ( isto é, há apenas 80 MiB de RAM). O valor máximo imposto pelo kernel é o valor máximo que pode ser armazenado em uma variável do tipo long em C em sua arquitetura.

Se você aumentar file-max, você também deve aumentar inode-max; a documentação do kernel diz que isso deve ser “3-4 vezes maior que o valor em file-max, já que stdin, stdout e sockets de rede também precisam de uma estrutura de inode para lidar com eles. ”

Observe que clicar em file-max resultará em uma mensagem de registro do kernel dizendo“ VFS: limite máximo de arquivo n atingido ”, Com o valor apropriado para n . Se você não tem isso em seus registros, não está acessando file-max ou filtrando muito seus registros (é uma mensagem de registro em nível de informação).

(file-max não limita os processos com CAP_SYS_ADMIN, então bater nele não vai parar tudo.)

Comentários

  • Portanto, não há nenhuma desvantagem em ter números arbitrariamente altos? Eu não ' não vejo inode-max em meu sistema em qualquer lugar? Ubuntu 16.04 aqui. Eu só quero evitar que meu servidor falhe novamente. Eu executo vários serviços da web neste servidor e não ' não me importo com a utilização de recursos
  • A desvantagem é que os processos descontrolados não será pego pelo limite geral de descrições de arquivo, então eles podem causar falta de recursos de outras maneiras.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *