Maior número máximo permitido de arquivos abertos no Linux

10

Existe um limite (técnico ou prático) para o tamanho em que você pode configurar o número máximo de arquivos abertos no Linux? Existem alguns efeitos adversos se você configurá-lo para um número muito grande (por exemplo, 1-100M)?

Estou pensando em uso do servidor aqui, não em sistemas embarcados. É claro que programas que usam grandes quantidades de arquivos abertos podem consumir memória e ficar lentos, mas estou interessado em efeitos adversos se o limite for configurado muito maior que o necessário (por exemplo, memória consumida apenas pela configuração).

— Sampo
fonte

Em teoria, você poderia calcular quantos descritores de arquivo seu sistema poderia lidar com base na memória disponível e na afirmação de que cada fd consome 1K de memória: serverfault.com/questions/330795/…

— Alastair McCormack

10

Suspeito que o principal motivo do limite seja evitar o consumo excessivo de memória (cada descritor de arquivo aberto usa memória do kernel). Ele também serve como uma proteção contra aplicativos de bugs vazando descritores de arquivos e consumindo recursos do sistema.

Mas, considerando a quantidade absurda de sistemas modernos de RAM em comparação com os sistemas há 10 anos, acho que os padrões hoje são bastante baixos.

Em 2011, o limite rígido padrão para descritores de arquivos no Linux aumentou de 1024 para 4096 .

Alguns softwares (por exemplo, MongoDB) usam muito mais descritores de arquivo que o limite padrão. O pessoal do MongoDB recomenda aumentar esse limite para 64.000 . Eu usei um rlimit_nofilede 300.000 para determinadas aplicações.

Desde que você mantenha o limite flexível no padrão (1024), provavelmente é bastante seguro aumentar o limite rígido. Os programas precisam chamar setrlimit()para aumentar seu limite acima do limite flexível e ainda são limitados pelo limite rígido.

Veja também algumas perguntas relacionadas:

— AB
fonte

6

No entanto, isso não respondeu à pergunta, que perguntou se havia um limite técnico ou prático para o quão alto é possível definir o limite rígido . Existe, mas esta resposta não menciona nada.

— JdeBP

Estou achando impossível aumentar o limite além de cerca de 1 milhão. Eu acho que pode ser codificado no kernel, porque, apesar de alterar muitas configurações, não posso ir além disso. superuser.com/questions/1468436/…

— Pavel Komarov

3

O impacto normalmente não seria observável, mas o módulo de E / S do kernel precisará cuidar de todos esses descritores de arquivos abertos e também poderá ter um impacto na eficiência do cache.

Esses limites têm a vantagem de proteger o usuário de seus próprios erros (ou de terceiros). Por exemplo, se você executar um pequeno programa ou script que se bifurca por tempo indeterminado, ele eventualmente será bloqueado em um dos se ulimitevitará um congelamento mais intenso (possivelmente irrecuperável) do computador.

A menos que você tenha razões precisas para aumentar qualquer um desses limites, evite-o e durma melhor.

— Julie Pelletier
fonte

2

É tecnicamente limitado ao valor máximo de tempo sem assinatura (C Lang), ou seja, 4.294.967.295

Referência: fs.hfile

/* And dynamically-tunable limits and defaults: */
struct files_stat_struct {
  unsigned long nr_files;   /* read only */
  unsigned long nr_free_files;  /* read only */
  unsigned long max_files;    /* tunable THIS IS OUR VALUE */
};

— Leonard T
fonte

2

Você tem alguma referência para isso?

— Tim

Além disso, esse é o valor máximo para o número inteiro assinado de 32 bits; o valor máximo do número inteiro não assinado de 32 bits é 4.294.967.295.

— Sampo

Você está certo, Sampo. Meu erro.

— Leonard T

0

Acho que sua preocupação é compreensível, mas provavelmente o Linux não consumirá muita memória para os descritores de arquivos configurados (mas não usados) :)

Não me lembro de um problema assim na minha carreira profissional nos últimos 10 anos.

Saudações.

— Tim Connor
fonte

0

Tarde demais, mas isso deve ajudar todos os outros a obter a resposta para esta pergunta. O limite prático para o número de arquivos abertos no linux também pode ser contado usando o número máximo de descritores de arquivos que um processo pode abrir.

Vi limites sendo alterados de sistema para sistema. Na página do manual getlimit , você pode ver que RLIMIT_NOFILE-1especifica os limites internamente.

Para verificar o valor RLIMIT_NOFILE, você pode usar a instrução abaixo para obter uma tupla

python -c "import resource; print(resource.getrlimit(resource.RLIMIT_NOFILE))"

A tupla retorna resultados como (Soflimit, hardlimit). Para mim, rodando em vários sistemas, os resultados são como abaixo

(1024, 1048576) # on UBUNTU linux 
(65536, 65536)  # on amazon linux 
(1024, 9223372036854775807) # on macos

Nota: 9223372036854775807 esse número significa simplesmente infinito. Você sempre alcançará outros limites de recursos antes de atingir isso. Se você modificar o limite máximo de um sistema além do que é, terá que modificar os parâmetros do kernel.

— Ankit Kulkarni
fonte