Il numero massimo consentito di file aperti in Linux


10

Esiste un limite (tecnico o pratico) a quanto è possibile configurare il numero massimo di file aperti in Linux? Ci sono alcuni effetti negativi se lo si configura su un numero molto grande (diciamo 1-100 M)?

Sto pensando all'utilizzo del server qui, non ai sistemi integrati. I programmi che usano enormi quantità di file aperti possono ovviamente consumare memoria ed essere lenti, ma sono interessato a effetti negativi se il limite è configurato molto più grande del necessario (ad es. Memoria consumata solo dalla configurazione).


In teoria, potresti calcolare quanti descrittori di file il tuo sistema potrebbe gestire in base alla memoria disponibile e all'asserzione che ogni fd consuma 1K di memoria: serverfault.com/questions/330795/…
Alastair McCormack

Risposte:


10

Sospetto che il motivo principale del limite sia evitare un consumo eccessivo di memoria (ogni descrittore di file aperto utilizza la memoria del kernel). Serve anche come protezione contro le applicazioni difettose che perdono descrittori di file e consumano risorse di sistema.

Ma dato quanto assurdamente RAM i sistemi moderni hanno paragonato ai sistemi 10 anni fa, penso che le impostazioni predefinite oggi siano piuttosto basse.

Nel 2011 il limite rigido predefinito per i descrittori di file su Linux è stato aumentato da 1024 a 4096 .

Alcuni software (ad esempio MongoDB) utilizzano molti più descrittori di file rispetto al limite predefinito. La gente di MongoDB consiglia di aumentare questo limite a 64.000 . Ho usato rlimit_nofile300.000 per alcune applicazioni.

Finché si mantiene il limite soft sul valore predefinito (1024), è probabilmente abbastanza sicuro aumentare il limite hard. I programmi devono chiamare setrlimit()per innalzare il loro limite al di sopra del limite soft e sono ancora limitati dal limite hard.

Vedi anche alcune domande correlate:


6
Questo non ha effettivamente risposto alla domanda, che ha chiesto se esistesse un limite tecnico o pratico su quanto in alto si possa impostare il limite rigido . C'è, ma questa risposta non lo menziona affatto.
JdeBP,

Trovo impossibile aumentare il limite oltre circa 1 milione. Penso che potrebbe essere hardcoded nel kernel, perché nonostante abbia cambiato molte configurazioni, non posso andare oltre. superuser.com/questions/1468436/…
Pavel Komarov

3

L'impatto non sarebbe normalmente osservabile, ma il modulo IO del kernel dovrà occuparsi di tutti quei descrittori di file aperti e potrebbero anche avere un impatto sull'efficienza della cache.

Tali limiti hanno il vantaggio di proteggere l'utente da errori propri (o di terzi). Ad esempio, se si esegue un programma o uno script di piccole dimensioni che esegue una fork a tempo indeterminato, alla fine si bloccherà su una delle ulimits e quindi impedirà un blocco del computer più intenso (forse irrecuperabile).

A meno che tu non abbia ragioni precise per aumentare uno di questi limiti, dovresti evitarlo e dormire meglio.


2

È tecnicamente limitato al valore massimo di unsigned long (C Lang) ovvero 4.294.967.295

Riferimento: 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 */
};

2
Hai qualche riferimento per questo?
Tim

Anche questo è il valore massimo per il 32 bit firmato intero a 32 bit valore massimo numero intero senza segno è 4,294,967,295.
Sampo,

Hai ragione, Sampo. Errore mio.
Leonard T,

0

Penso che la tua preoccupazione sia comprensibile, ma molto probabilmente Linux non consumerà molta memoria per i descrittori di file configurati (ma non usati) :)

Non ricordo un simile problema nella mia carriera professionale negli ultimi 10 anni.

Saluti.


0

Tranquillo in ritardo, ma questo dovrebbe aiutare tutti gli altri a ottenere la risposta a questa domanda. Il limite pratico per il numero di file aperti in Linux può anche essere contato usando il numero massimo di descrittori di file che un processo può aprire.

Ho visto cambiare i limiti da un sistema all'altro. Dalla pagina man getlimit puoi vedere che RLIMIT_NOFILE-1specifica i limiti internamente.

Per controllare il valore RLIMIT_NOFILE è possibile utilizzare l'istruzione seguente per ottenere una tupla

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

La tupla restituisce risultati come (Soflimit, hardlimit). Per me in esecuzione su più sistemi i risultati sono come di seguito

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

Nota: 9223372036854775807 questo numero significa semplicemente infinito. Raggiungerai sempre altri limiti di risorse prima di raggiungerlo. Se devi modificare hardlimit su un sistema oltre quello che è, dovrai modificare i parametri del kernel.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.