Trovare il collo di bottiglia Nginx / PHP-FPM che sta causando errori casuali 502 gateway

Lavoro per un sito web piuttosto occupato che spesso ottiene picchi di traffico molto grandi. Durante questi picchi vengono richieste centinaia di pagine al secondo e questo produce errori casuali di gateway 502.

Ora eseguiamo Nginx (1.0.10) e PHP-FPM su una macchina con unità 4x SAS 15k (raid10) con una CPU a 16 core e 24GB di RAM DDR3. Inoltre utilizziamo l'ultima versione di Xcache. Il DB si trova su un'altra macchina, ma il carico di questa macchina è molto basso e non ha problemi.

  • Reindirizzare più domini a SSL - NGINX
  • come colbind la macchina di linux / centos alla port del trunk
  • Problemi di memory condivisi APC
  • Come rilevare lo ssl nella condivisione 80s / ssl nginx config server?
  • Problemi di installazione di PHP 5.4.11 e MySQL 5.6.10 su CentOS 6.3
  • Nginx - root contro alias, per la distribuzione di file singoli?
  • In un normale carico tutto è perfetto, il carico di sistema è inferiore a 1 e il rapporto di stato PHP-FPM non mostra mai più di 10 processi attivi contemporaneamente. Ci sono sempre circa 10GB di ram ancora disponibili. Al carico normale la macchina gestisce circa 100 pagine visualizzate al secondo.

    Il problema si presenta quando arrivano enormi picchi di traffico e vengono richieste centinaia di visualizzazioni di pagina per secondo dalla macchina. Vedo che il rapporto di stato del FPM mostra poi fino a 50 processi attivi, ma è ancora al di sotto delle 300 connessioni max che abbiamo configurato. Durante questi picchi, il rapporto Nginx riport fino a 5000 connessioni attive invece della normale media di 1000.

    OS Info: CentOS release 5.7 (Finale)

    CPU: CPU Intel (R) Xeon (R) E5620 @ 2.40GH (16 core)

    php-fpm.conf

    daemonize = yes listen = /tmp/fpm.sock pm = static pm.max_children = 300 pm.max_requests = 1000 

    Non ho installato rlimit_files, perché per quanto ne so lo dovrebbe usare il sistema predefinito se non lo fai.

    fastcgi_params (solo valori aggiunti al file standard)

     fastcgi_connect_timeout 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; fastcgi_intercept_errors on; fastcgi_pass unix:/tmp/fpm.sock; 

    nginx.conf

     worker_processes 8; worker_connections 16384; sendfile on; tcp_nopush on; keepalive_timeout 4; 

    Nginx si connette a FPM tramite Unix Socket.

    sysctl.conf

     net.ipv4.ip_forward = 0 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0 kernel.sysrq = 1 kernel.core_uses_pid = 1 net.ipv4.tcp_syncookies = 1 kernel.msgmnb = 65536 kernel.msgmax = 65536 kernel.shmmax = 68719476736 kernel.shmall = 4294967296 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.tcp_max_syn_backlog = 2048 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.all.log_martians = 1 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_ignore_bogus_error_responses = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.tcp_timestamps = 0 net.ipv4.conf.all.rp_filter=1 net.ipv4.conf.default.rp_filter=1 net.ipv4.conf.eth0.rp_filter=1 net.ipv4.conf.lo.rp_filter=1 net.ipv4.ip_conntrack_max = 100000 

    limits.conf

     * soft nofile 65536 * hard nofile 65536 

    Questi sono i risultati per i seguenti comandi:

     ulimit -n 65536 ulimit -Sn 65536 ulimit -Hn 65536 cat /proc/sys/fs/file-max 2390143 

    Domanda: se il PHP-FPM non sta esaurendo le connessioni, il carico è ancora basso e ci è abbondanza di RAM disponibile, quale collo di bottiglia potrebbe causare questi errori di gateway casuali 502 durante un traffico elevato?

    Nota: per impostazione predefinita, questa macchina era di 1024, poiché l'ho cambiata a 65536 non ho completamente riavviato la macchina, dato che è una macchina di produzione e significherebbe troppo tempo di inattività.

  • connect () non riuscito (111: Connessione rifiutata) durante la connessione a monte
  • Nginx + PHP-FPM = "Casuale" 502 Bad Gateway
  • (111: Connessione rifiutata) durante la connessione a monte - Opsworks Rails 4
  • nginx 502 bad gateway - fastcgi non ascoltare? (Debian 5)
  • Errore nginx che accusa la connessione rifiutata alla port PHP-FPM
  • 2 Solutions collect form web for “Trovare il collo di bottiglia Nginx / PHP-FPM che sta causando errori casuali 502 gateway”

    Raccomandazione ufficiale: worker_processes = numero di core CPU

    set worker_processes 16;

    Gli errori Sporadic 502 dai bilanciatori di carico, come HAProxy e nginx, sono solitamente causati da qualcosa che ha tagliato la metà di stream tra il LB e il server Web.

    Provare a eseguire uno dei tuoi server web o una copia di prova tramite GDB e vedere se si visualizza un errore di segmentazione durante la generazione del traffico di prova (utilizzare ab o jMeter o simile per simulare il traffico).

    Ho dovuto risolvere recentemente uno scenario / problema molto simile. Avevo escluso risorse ecc, causando la questione perché avevo un monitoraggio abbastanza completo che mi stava aiutando. Alla fine ho scoperto che l'errore 502 era venuto dal server web dietro l'equilibratore di carico che non restituiva (in questo caso vuota) le risposte HTTP al LB.

    Ho preso uno dei server web e ho interrotto il server web, poi ho iniziato nuovamente tramite gdb, quindi ho visitato il sito. Finalmente dopo un po 'di scorrimento ho visto un errore di segmentazione accadere e questo ha causato un errore 502 per essere visibile. Ho preso la backtrace da GDB e l'ho presentata al team PHP come bug, ma l'unica soluzione per me è stata quella di passare la distribuzione a lavorare intorno al bug PHP che era lì.

    Il segfault stava causando che il server web inviasse un contenuto non valido al LB e il LB stava visualizzando un errore 502 perché per quanto riguarda il server web è scomparso "mid flow".

    So che questo non risponde direttamente alla tua domanda, ma è un posto per iniziare a cercare. Supponendo di vedere un segfault è ansible get la traccia di stack da GDB, allora si può sperare di lavorare all'indietro e trovare la function che causa l'errore di segmentazione.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.