Perché il numero di file aperti è limitato in Linux?

136

In questo momento, so come:

trova limite di file aperti per processo: ulimit -n
contare tutti i file aperti da tutti i processi: lsof | wc -l
ottenere il numero massimo consentito di file aperti: cat /proc/sys/fs/file-max

La mia domanda è: perché esiste un limite di file aperti in Linux?

open-files limit

— xanpeng
fonte

2

@Rob Googled un po 'e scopri che è una bomba a forcella , può essere usato per spiegare il limite di file aperti?

— xanpeng,

6

Bene, i limiti di processo e i limiti di file sono importanti, quindi cose come le bombe a forcella non rompono un server / computer per tutti gli utenti, solo l'utente che lo fa e solo temporaneamente. Altrimenti, qualcuno su un server condiviso potrebbe innescare un forkbomb e abbatterlo completamente per tutti gli utenti, non solo se stessi.

— Rob,

3

Bello quello che riassume alcuni comandi molto utili! : +1:

— Joshua Pinter

7

@Rob, una bomba a forcella non ha nulla a che fare con esso poiché il limite del file è per processo e ogni volta che si biforca non apre un nuovo handle di file.

— psusi,

86

Il motivo è che il sistema operativo ha bisogno di memoria per gestire ogni file aperto e la memoria è una risorsa limitata, specialmente sui sistemi incorporati.

Come utente root puoi cambiare il numero massimo di file aperti per processo (via ulimit -n) e per sistema (es echo 800000 > /proc/sys/fs/file-max.).

— Jofel
fonte

21

C'è anche un motivo di sicurezza: se non ci fossero limiti, un software userland sarebbe in grado di creare file all'infinito fino a quando il server non si arresta.

— Coren,

15

@Coren I limiti qui discussi sono solo per il conteggio dei gestori di file aperti. Poiché un programma può anche chiudere i gestori di file, potrebbe creare tutti i file e le dimensioni che desidera, fino a quando tutto lo spazio disponibile su disco è pieno. Per evitare ciò, è possibile utilizzare quote del disco o partizioni separate. Sei vero nel senso che un aspetto della sicurezza sta impedendo l'esaurimento delle risorse - e per questo ci sono dei limiti.

— jofel,

1

@jofel Grazie. Suppongo che gli handle di file aperti siano rappresentati da istanze di file struct e che le dimensioni di questa struttura siano piuttosto ridotte (livello di byte), quindi posso impostare /.../file-maxcon un valore abbastanza grande purché la memoria non sia esaurita?

— xanpeng,

7

@xanpeng Non sono un esperto del kernel, ma per quanto posso vedere, l'impostazione predefinita file-maxsembra essere la dimensione della RAM divisa per 10k. Poiché la memoria reale utilizzata per il gestore di file dovrebbe essere molto più piccola (dimensione della struct filememoria aggiuntiva dipendente dal driver), questo sembra un limite abbastanza conservativo.

— jofel,

63

Si noti che lsof | wc -lriassume molte voci duplicate (i processi biforcati possono condividere handle di file, ecc.). Quel numero potrebbe essere molto più alto del limite stabilito /proc/sys/fs/file-max.

Per ottenere il numero corrente di file aperti dal punto di vista del kernel Linux, procedere come segue:

cat /proc/sys/fs/file-nr

Esempio: questo server ha 40096 su un massimo di 65536 file aperti, anche se lsof riporta un numero molto più grande:

# cat /proc/sys/fs/file-max
65536
# cat /proc/sys/fs/file-nr 
40096   0       65536
# lsof | wc -l
521504

— grebneke
fonte

1

Come lsofsegnaleremo molti file due o più volte, ad esempio /dev/null, puoi provare a indovinare meglio con:lsof|awk '{print $9}'|sort|uniq|wc -l

— Yvan

è possibile utilizzare lsof|awk '!a[$NF]++{c++}END{print c}'per ottenere il conteggio non duplicato di file aperti.

— P ....

18

Penso che sia in gran parte per motivi storici.

Un descrittore di file Unix è un piccolo intvalore restituito da funzioni come opene creat, e passato a read, write, closee così via.

Almeno nelle prime versioni di Unix, un descrittore di file era semplicemente un indice in una matrice di strutture per processo a dimensione fissa, in cui ogni struttura contiene informazioni su un file aperto. Se ricordo bene, alcuni dei primi sistemi limitavano le dimensioni di questa tabella a circa 20.

I sistemi più moderni hanno limiti più elevati, ma hanno mantenuto lo stesso schema generale, in gran parte per inerzia.

— Keith Thompson
fonte

1

20 era il limite di Solaris per le strutture di dati FILE in linguaggio C. Il conteggio degli handle di file era sempre maggiore.

— Lothar,

@Lothar: interessante. Mi chiedo perché i limiti sarebbero diversi. Date le funzioni filenoe fdopen, mi aspetto che siano quasi intercambiabili.

— Keith Thompson,

Un file unix è molto più del semplice handle di file (int) restituito. Esistono buffer del disco e un blocco di controllo del file che definisce l'offset del file corrente, il proprietario del file, le autorizzazioni, l'inode, ecc.

— ChuckCottrill

@ChuckCottrill: Sì, certo. Ma la maggior parte di tali informazioni deve essere memorizzata se si accede a un file tramite un intdescrittore o un FILE*. Se hai più di 20 file aperti tramite open(), fdopen()fallirebbe?

— Keith Thompson,