Troppi file aperti con nginx non sembrano alzare il limite

22

Il server è Ubuntu 13.04 (GNU / Linux 3.9.3-x86_64-linode33 x86_64).

nginx è nginx / 1.2.6.

Ci sto lavorando da diverse ore, quindi ecco cosa sto ottenendo ed ecco cosa ho fatto.

tail -f /usr/local/nginx/logs/error.log
2013/06/18 21:35:03 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:05 [crit] 3426#0: accept4() failed (24: Too many open files)

Nginx in esecuzione:

geuis@localhost:~$ ps aux | grep nginx
root      3422  0.0  0.0  39292   380 ?        Ss   21:30   0:00 nginx: master process /usr/local/nginx/sbin/nginx
nobody    3423  3.7 18.8 238128 190848 ?       S    21:30   0:13 nginx: worker process      
nobody    3424  3.8 19.0 236972 192336 ?       S    21:30   0:13 nginx: worker process      
nobody    3426  3.6 19.0 235492 192192 ?       S    21:30   0:13 nginx: worker process      
nobody    3427  3.7 19.0 236228 192432 ?       S    21:30   0:13 nginx: worker process      
nobody    3428  0.0  0.0  39444   468 ?        S    21:30   0:00 nginx: cache manager process

Limiti soft / hard modificati in /etc/security/limits.conf (impostazioni dalla fine del file)

root soft  nofile 65536
root hard  nofile 65536

www-data soft nofile 65536
www-data hard nofile 65536

nobody soft nofile 65536
nobody hard nofile 65536

Una lettura dei file max

cat /proc/sys/fs/file-max
500000

E in /etc/pam.d/common-session:

session required pam_limits.so

Con questo aggiunto e il server riavviato per buona misura, per nginx conto i limiti soft / hard ottenendo il PID del processo padre e:

cat /proc/<PID>/limits
Limit                     Soft Limit           Hard Limit           Units     
Max open files            1024                 4096                 files

Il processo genitore funziona come 'root' e i 4 lavoratori funzionano come 'nessuno'.

root      2765  0.0  0.0  39292   388 ?        Ss   00:03   0:00 nginx: master process /usr/local/nginx/sbin/nginx
nobody    2766  3.3 17.8 235336 180564 ?       S    00:03   0:21 nginx: worker process      
nobody    2767  3.3 17.9 235432 181776 ?       S    00:03   0:21 nginx: worker process      
nobody    2769  3.4 17.9 236096 181524 ?       S    00:03   0:21 nginx: worker process      
nobody    2770  3.3 18.3 235288 185456 ?       S    00:03   0:21 nginx: worker process      
nobody    2771  0.0  0.0  39444   684 ?        S    00:03   0:00 nginx: cache manager process

Ho provato tutto ciò che so fare e sono stato in grado di ottenere da Google. Non riesco a ottenere i limiti di file per aumentare nginx.

Aiuto?

nginx ulimit file-descriptors

— Geuis
fonte

32

Aggiungi la seguente riga a nginx e riavvia il processo:

worker_rlimit_nofile 30000;

Ciò consentirà ai lavoratori di acquisire più file. È quindi possibile verificare con:

su - nobody ulimit -Hn ulimit -Sn

Ciò dovrebbe generare i nuovi limiti hard / soft.

Riferimento

— Nathan C
fonte

6

Se modifichi solo l' worker_rlimit_nofileimpostazione uWSGI e non i limiti del sistema (che ha funzionato per me), non puoi verificarlo tramite ulimit. Invece, dovresti guardare direttamente /proc/<pid of worker>/limits.

— Jan Fabry,

Penso che l'utente (nessuno / dati www) debba disconnettersi e riconnettersi. Vale a dire. riavvia il server. ulimit per me sta dimostrando che è aumentato, ma il processo è ancora limitato secondo cat / proc / {pid} / limits

— felix

@felix L'OP ha menzionato che hanno già riavviato il server, ma sì, questo è necessario.

— Nathan C,

3

In Ubuntu, modifica /etc/pam.d/su aggiungi o decommenta la sessione di linea richiesta pam_limits.so

Inoltre, in /etc/security/limits.conf assicurati di avere TAB tra i caratteri e non gli spazi.

— Rusty Hodge
fonte

1

assicurarsi di eseguire il comando seguente dopo aver modificato quei file

sysctl -p

Quindi riavviare nginx

— Mike
fonte

1

Non ha alcun effetto. I limiti sono rimasti gli stessi.

— Geuis,