Pratici descrittori di file aperti massimi (ulimit -n) per un sistema ad alto volume

Di recente abbiamo iniziato a testare il carico della nostra applicazione e abbiamo notato che si esaurivano i descrittori di file dopo circa 24 ore.

Stiamo eseguendo RHEL 5 su un Dell 1955:

CPU: 2 x Dual Core 2,66 GHz 4 MB 5150 / 1333FSB RAM: 8 GB RAM HDD: 2 x 160 GB 2,5 "dischi rigidi SATA

Ho controllato il limite del descrittore di file ed era impostato su 1024. Considerando che la nostra applicazione potrebbe potenzialmente avere circa 1000 connessioni in entrata e 1000 connessioni in uscita, questo sembra piuttosto basso. Per non parlare dei file effettivi che devono essere aperti.

Il mio primo pensiero è stato quello di aumentare il parametro ulimit -n di alcuni ordini di grandezza e quindi rieseguire il test, ma volevo conoscere eventuali potenziali ramificazioni di impostazione di questa variabile troppo alta.

Ci sono delle migliori pratiche per impostare questo oltre a capire quanti descrittori di file il nostro software può teoricamente aprire?

Questi limiti provenivano da un'epoca in cui più utenti "normali" (non app) condividevano il server e avevamo bisogno di modi per proteggerli dall'uso di troppe risorse.

Sono molto bassi per server ad alte prestazioni e generalmente li impostiamo su un numero molto alto. (24k o giù di lì) Se hai bisogno di numeri più alti, devi anche cambiare l'opzione sysctl file-max (generalmente limitata a 40k su ubuntu e 70k su rhel).

Impostazione ulimit:

# ulimit -n 99999

File Sysctl max:

#sysctl -w fs.file-max=100000

Inoltre, e molto importante, potrebbe essere necessario verificare se l'applicazione presenta una perdita nel descrittore di memoria / file. Usa lsof per vedere tutto ciò che ha aperto per vedere se sono validi o meno. Non tentare di modificare il sistema per aggirare i bug delle applicazioni.

Potresti sempre e basta

cat /proc/sys/fs/file-nr

Durante la situazione di "carico elevato" per vedere quanti descrittori di file sono in uso.

Quanto al massimo - dipende solo da cosa stai facendo.

Se i descrittori di file sono socket tcp, ecc., Si rischia di utilizzare una grande quantità di memoria per i buffer socket e altri oggetti del kernel; questa memoria non sarà scambiabile.

Ma per il resto no, in linea di principio non dovrebbero esserci problemi. Consultare la documentazione del kernel per provare a capire quanta memoria del kernel utilizzerà e / o testarla.

Eseguiamo server di database con descrittori di file ~ 10k aperti (principalmente su file di dischi reali) senza un grosso problema, ma sono a 64 bit e hanno un sacco di RAM.

L'impostazione ulimit è per processo, ma esiste anche un limite a livello di sistema (32k penso di default)

Non sono personalmente a conoscenza delle migliori pratiche. È in qualche modo soggettivo a seconda della funzione di sistema.

Ricorda che 1024 che stai vedendo è un limite per utente e non un limite a livello di sistema. Considera quante applicazioni esegui su questo sistema. Questo è l'unico? L'utente che esegue questa applicazione sta facendo qualcos'altro? (IE hai umani che usano questo account per accedere ed eseguire script che potrebbero scappare?)

Dato che la scatola esegue solo questa applicazione e l'account che esegue tale applicazione è solo a tale scopo, non vedo alcun danno nell'aumentare il limite come suggerisci. Se è un team di sviluppo interno, chiederei la loro opinione. Se provengono da un fornitore di terze parti, potrebbero avere requisiti o raccomandazioni specifici.

Questa mi sembra una di quelle domande a cui si risponde meglio con "testarlo in un ambiente di sviluppo". Ricordo che anni fa Sun si innervosiva quando si sbagliava, ma non così nervoso. Il limite all'epoca era anche 1024, quindi sono un po 'sorpreso di vedere che è lo stesso adesso per Linux, sembra che dovrebbe essere più alto.

Ho trovato educativo il seguente link quando ho cercato su Google le risposte alla tua domanda: http://www.netadmintools.com/art295.html

E anche questo: https://stackoverflow.com/questions/1212925/on-linux-set-ma maximum - open - files - to - unlimited - possible