2012-05-06 15 views
43

Ho qualche errore con subj. Il server non è caricato in alto: ~ 15% CPU, ci sono diversi GB di memoria, l'HDD non è buisy. Ma l'errore 502 genera approssimativamente nel 3% dei casi.Errore 502 in nginx + php5-fpm

Programmi: Debian 6, nginx/0.7.62, php5-fpm (5.3.3-1).

In error.log di nginx è questo errore:

connect() to unix:/var/run/php5-fpm.sock failed 

Stato di PHP5-fpm di solito in questo modo:

accepted conn: 41680 
pool:    www 
process manager: dynamic 
idle processes: 258 
active processes: 1 
total processes: 259 

penso, questo significa che il caricamento non è elevato.

Ho aumentato i parametri del backlog: in sysctl - net.core.somaxconn = 5000, nel pool php-fpm - listen.backlog = 5000. Nessun effetto.

cito una configurazione:

/etc/nginx/nginx.conf

user www-data; 
worker_processes 8; 
timer_resolution 100ms; 
worker_rlimit_nofile 20240; 
worker_priority -5; 

error_log /var/log/nginx/error.log; 
pid  /var/run/nginx.pid; 

events { 
    worker_connections 2048; 
    use epoll; 
    # multi_accept on; 
} 

http { 
    include  /etc/nginx/mime.types; 

    access_log /var/log/nginx/access.log; 

    sendfile  on; 
    tcp_nopush  on; 

    #keepalive_timeout 0; 
    keepalive_timeout 65; 
    tcp_nodelay  on; 

    gzip on; 
    gzip_min_length 1100; 
    gzip_buffers 64 8k; 
    gzip_comp_level 3; 
    gzip_http_version 1.1; 
    gzip_proxied any; 
    gzip_types text/plain application/xml application/x-javascript text/css; 
    gzip_disable "MSIE [1-6]\.(?!.*SV1)"; 

    include /etc/nginx/conf.d/*.conf; 
    include /etc/nginx/sites-enabled/*; 

    client_max_body_size 100M; 
    server_tokens off; 
} 

/etc/nginx/php_location

fastcgi_pass unix:/var/run/php5-fpm.sock; 
fastcgi_index index.php; 
fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name; 
fastcgi_buffers 256 128k; 
#fastcgi_buffer_size 16k; 
#fastcgi_busy_buffers_size 256k; 
fastcgi_connect_timeout 300s; 
fastcgi_send_timeout 300s; 
fastcgi_read_timeout 300s; 
include fastcgi_params; 

piscina php-fpm

[www] 
listen = /var/run/php5-fpm.sock 
listen.backlog = 5000 
listen.owner = www-data 
listen.group = www-data 
listen.mode = 0666 
user = www-data 
group = www-data 
pm = dynamic 
pm.max_children = 1024 
pm.start_servers = 64 
pm.min_spare_servers = 64 
pm.max_spare_servers = 128 
pm.max_requests = 32000 
pm.status_path = /system/php5-fpm-status 
slowlog = /var/www/log/php-fpm.log.slow 
chdir = /var/www 

Cosa posso fare per ottimizzare questo sistema e utilizzare tutte le risorse del server?

PS. Mi dispiace, il mio inglese è cattivo.

+2

sono su Ubuntu 13.10 e la registrazione di PHP5-fpm è in qualche modo travisare quello che succede ... in realtà, il i registri non hanno detto nulla :) Ho trovato l'errore eseguendo il daemon direttamente dalla riga di comando, invece, 'sudo php5-fpm - -daemonize --fpm-config/etc/php5/fpm/php-fpm.conf' – benjaoming

+7

nel caso qualcuno stia cercando il file php-fpm pool in /etc/php5/fpm/pool.d/www.conf on Ubuntu 12.04.3 LTS –

+0

Per coloro che vengono a questa domanda da googling: provare prima questa soluzione: http://stackoverflow.com/questions/23443398/nginx-error-connect-to-php5-fpm-sock-failed-13 -permission-negato – Alexar

risposta

102

Il problema è il socket stesso, i suoi problemi nei casi di carico elevato sono ben noti. Si prega di considerare l'utilizzo di connessione TCP \ IP anziché socket UNIX, per questo è necessario apportare queste modifiche:

  • in php-fpm configurazione del pool sostituire listen = /var/run/php5-fpm.sock con listen = 127.0.0.1:7777
  • in /etc/nginx/php_location sostituire fastcgi_pass unix:/var/run/php5-fpm.sock; con fastcgi_pass 127.0.0.1:7777;
+0

Precedentemente, era proprio così: veniva usato il socket TCP/IP. Ma la situazione era la stessa. Proverò di nuovo il socket TCP/IP - vedrà, cosa ci dà. – andre487

+2

Ora è molto meglio. Inoltre, voglio dire che aggiornare PHP alla versione 5.4 ha un effetto molto positivo. – andre487

+0

Sì, è sparito. nginx è aggiornato alla versione 1.1.19. Ho pensato di eseguire il caching su nginx, ma nell'applicazione corrente non sarà utile. – andre487

-6

ho lo stesso problema, ma non ha voluto passare da socket a TCP/IP. Il riavvio di php-fpm e nginx risolverà il problema.

sudo /etc/init.d/php-fpm restart 
sudo /etc/init.d/nginx restart 
+1

Il riavvio dell'applicazione ogni volta che si verifica un problema non può essere considerato una soluzione. – GeekRide

+0

A seconda della frequenza del problema e della quantità di risorse allocabili, sì, può essere una soluzione. Il punto fondamentale che * i sistemi dovrebbero essere meglio progettati * rimane, naturalmente, –

+0

@GeekRide se la situazione richiedeva l'uso di una connessione socket, quindi come DmitryV affermava "i suoi problemi su casi di carico elevato sono ben noti", vorremmo non hanno altra scelta che riavviare strategicamente il servizio. Penso che sia triste che così tante persone trascurino questo perché lavorano in ambienti con costi di produzione inferiori. –

2

su CentOS 7, Plesk 12.5

Ho avuto questo problema dopo la mia harddisc andato piena e alcuni servizi non è riuscita. Altri domini funzionano perfettamente, ma nessuno di essi mi ha dato solo 502 e simili come timeout. Dal log degli errori:

[crit] 3112#0: *65746768 connect() to 
unix:///var/www/vhosts/system/sub.domain.de/php-fpm.sock failed 
(2: No such file or directory) while connecting to upstream 

per risolverlo, ho dovuto (prima fare spazio a disposizione e poi) riavvio php-fpm e nginx - allora questo errore sparito!

0

L'unica ragione per questo file non è creato configurazione a /etc/php-fpm.d/www.conf

Change ascoltare = 127.0.0.1:9000

Con ascoltare =/var/run /php-fpm/php-fpm.sock

e riavviare sia nginx e php-fpm

+0

Ho questa linea, riavviato entrambi ma il file non è ancora lì. Nessun errore in php5-fpm.log – Alecz

Problemi correlati