2012-07-19 12 views
17

Ho un ubuntu-server e un sito Web piuttosto alto. Server è:Nginx e php-fpm: impossibile eliminare gli errori 502 e 504

  • Dedicato a Nginx, usa php-FPM (senza apache), mysql si trova su una macchina diversa
  • dispone di 8 GB di RAM
  • Ottiene circa 2000 richieste al secondo.

Ogni processo php-fpm consuma circa 65 MB di RAM, secondo top comando:

top command

Memoria libera:

[email protected]:~$ free -m 
      total  used  free  shared buffers  cached 
Mem:   7910  7156  753   0  284  2502 
-/+ buffers/cache:  4369  3540 
Swap:   8099   0  8099 

PROBLEMA

Ultimamente, sto riscontrando grossi problemi di prestazioni. tempi di risposta molto grandi, molto numerosi Gateway Timeouts e nella sera, quando il carico diventa alto, il 90% degli utenti basta vedere "Server non trovato" al posto del sito web (non riesco a riprodurre questo)


TRONCHI

mio Nginx registro errori è pieno di messaggi maggese:

2012/07/18 20:36:48 [error] 3451#0: *241904 upstream prematurely closed connection while reading response header from upstream, client: 178.49.30.245, server: example.net, request: request: "GET /readarticle/121430 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "example.net", referrer: "http://example.net/articles" 

ho cercato di passare a presa unix, ma ancora ottenere questi errori:

2012/07/18 19:27:30 [crit] 2275#0: *12334 connect() to unix:/tmp/fastcgi.sock failed (2: No such file or directory) while connecting to upstream, client: 84. 
237.189.45, server: example.net, request: "GET /readarticle/121430 HTTP/1.1", upstream: "fastcgi://unix:/tmp/fastcgi.sock:", host: "example.net", referrer: "http 
://example.net/articles" 

e log php-FPM è piena di questi:

[18-Jul-2012 19:23:34] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 0 idle, and 75 total children 

Ho cercato di aumentare determinati parametri fino a 100, ma sembra ancora sufficiente.


CONFIGS

Ecco la mia configurazione attuale

php-fpm

listen = 127.0.0.1:9001 
listen.backlog = 4096 
pm = dynamic 
pm.max_children = 130 
pm.start_servers = 40 
pm.min_spare_servers = 10 
pm.max_spare_servers = 40 
pm.max_requests = 100 

nginx

worker_processes 4; 
worker_rlimit_nofile 8192; 
worker_priority 0; 
worker_cpu_affinity 0001 0010 0100 1000; 

error_log /var/log/nginx_errors.log; 

events { 
    multi_accept off; 
    worker_connections 4096; 
} 


http { 
    include  mime.types; 
    default_type application/octet-stream; 

    access_log off; 
    sendfile  on; 
    keepalive_timeout 65; 
    gzip on; 

    # fastcgi parameters 
    fastcgi_connect_timeout 120; 
    fastcgi_send_timeout 180; 
    fastcgi_read_timeout 1000; 
    fastcgi_buffer_size 128k; 
    fastcgi_buffers 4 256k; 
    fastcgi_busy_buffers_size 256k; 
    fastcgi_temp_file_write_size 256k; 
    fastcgi_intercept_errors on; 

    client_max_body_size 128M; 

    server { 
     server_name example.net; 
     root /var/www/example/httpdocs; 
     index index.php; 
     charset utf-8; 
     error_log /var/www/example/nginx_error.log; 

     error_page 502 504 = /gateway_timeout.html; 

     # rewrite rule 
     location/{ 
      if (!-e $request_filename) { 
       rewrite ^(.*)$ /index.php?path=$1 last; 
      } 
     } 
     location ~* \.php { 
      fastcgi_pass 127.0.0.1:9001; 
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
      fastcgi_param PATH_INFO $fastcgi_script_name; 
      include fastcgi_params; 
     } 
    } 
} 

Sarei molto grato per qualsiasi consiglio su come identificare il problema e quali parametri posso regolare per risolvere questo problema. O forse 8 GB di RAM non sono sufficienti per questo tipo di carico?

+0

Non sono molto sicuro delle specifiche della configurazione, ma è possibile calcolare la quantità di memoria che si sta consumando. Una rapida ipotesi potrebbe essere che i tuoi 130 bambini a 65 MB ciascuno necessitano di 8,5 gig (non si usano realmente cervelli per il problema 1000/1024, ma non si contano altri processi). Vorrei iniziare controllando se hai abbastanza memoria per far correre tutti quei bambini con tutti gli altri processi di gioco. – Nanne

+0

65mb è abbastanza per una pagina web. Vorrei verificare perché l'app Web è così affamata di risorse. Oltre a questo tutto è logico. 502 accade quando nginx non ha ricevuto una risposta adeguata da php5-fpm nel tempo. ATTENZIONE: [pool www] sembra occupato quando php5-fpm non è in grado di creare un altro processo Clild per elaborare la successiva query –

+1

Probabilmente i processi php-fpm sono bloccati in accesso MySQL. – VBart

risposta

1

Un numero di problemi. Vale ancora la pena risolverli con un sito così impegnativo. MySQL potrebbe essere la causa principale per ora. Ma a più lungo termine devi fare più lavoro.

Caching

vedo uno dei tuoi msg di errore che mostra una richiesta GET al php monte. Questo non sembra buono con un sito ad alto traffico (2000 r/s come hai detto). Questa pagina (/ readarticle/121430) sembra una pagina perfettamente memorizzabile nella cache. Per uno, è possibile utilizzare nginx per la memorizzazione nella cache di tali pagine. Scopri fastcgi cache

GET /readarticle/121430 

php-fpm

pm.max_requests = 100 

Il valore significa che un processo sarà ucciso da maestro php-fpm dopo aver scontato 100 richieste. php-fpm usa questo valore per combattere le perdite di memoria di terze parti. Il tuo sito è molto occupato, con 2000r/s. I tuoi processi figlio max sono 130, ognuno può servire solo al massimo 100 richieste. Ciò significa che dopo 13000/2000 = 6,5 secondi tutti verranno riciclati. Questo è troppo (20 processi uccisi ogni secondo). Dovresti almeno iniziare con un valore di 1000 e aumentare quel numero finché non vedi perdite di memoria. Qualcuno ne usa 10.000 in produzione.

nginx.conf

  • Problema 1:

    if (!-e $request_filename) { 
         rewrite ^(.*)$ /index.php?path=$1 last; 
        } 
    

    dovrebbe essere sostituito da try_files più efficienti:

    try_files $uri /index.php?path=$uri; 
    

Risparmi un extra se il blocco di posizione e una regola di riscrittura di espressioni regolari corrispondono.

  • Problema 2: utilizzando socket UNIX vi farà risparmiare più tempo rispetto all'utilizzo di IP (circa il 10-20% dalla mia esperienza). Ecco perché php-fpm lo sta usando come predefinito.

  • Problema 3: Potresti essere interessato a stabilire connessioni keepalive tra nginx e php-fpm. Un esempio è dato here nel sito ufficiale nginx.

+0

+1 per try_files. Il problema2, se sono corretto, può essere eseguito utilizzando i socket unix invece di tcp. Sto usando un setup molto simile a @ Silver Light e con unix socket, php-fpm e apc posso raggiungere 200k utenti su wordpress. – spinus

0

per il gusto di avere una risposta per questa domanda:

You should check your MySQL server. Probably it's overloaded or it limits count of parallel MySQL connections. You should find the bottleneck. And according to your top screenshot it doesn't look like either RAM or CPU, then it's most likely I/O. - @VBrat

cose che si potrebbe desiderare di fare in futuro:

1- aumentare la dimensione della RAM.

2- utilizzare la cache. vedi this article su come la cache può velocizzare il tuo sito

3- ridurre il numero di query che vengono eseguite.

1

Ho bisogno di vedere il tuo php.impostazioni ini e non penso che questo sia correlato a MySQL visto che si stanno verificando errori di socket. Inoltre, questo è qualcosa che inizia a verificarsi dopo un periodo di tempo o si verifica immediatamente quando il server si riavvia?

Provare a riavviare il demone php5-fpm e vedere cosa succede mentre si inserisce il log degli errori.

Controlla il tuo file php.ini e anche tutti i tuoi fastcgi_param situati in/etc/nginx/fastcgi_params. Ci sono un sacco di esempi per quello che stai cercando di fare.

Inoltre, è disponibile l'estensione apc php caching?

Si sarà simile a questa nel file php.ini se la vostra su una pila lampada:

extension = apc.so
....
apc.enabled = 0

Probabilmente wouldn' t male fare qualche test di caricamento della connessione mysql anche dalla riga di comando e vedere quali sono i risultati.

+0

APC è una cosa molto carina. Mi ha aiutato molto a mantenere il sito veloce (specialmente wordpress). – spinus

0
  • Imposta l'estensione APC per PHP (check/Configurazione)
  • MySQL - controllo della configurazione, indexs, query lente
  • Installare e configurare Varnish. Questo può memorizzare nella cache le richieste di pagina ed essere piuttosto utile nel ridurre la quantità di richieste php e di query mysql che è necessario effettuare. Può essere complicato con i cookie/ssl ma altrimenti non troppo difficile e molto utile per essere eseguito
Problemi correlati