2012-05-06 6 views
43

Ich habe einen Fehler mit subj. Server nicht hoch geladen: ~ 15% CPU, es gibt mehrere GB Speicher, HDD ist nicht buisy. Aber Fehler 502 löst ungefähr in 3% der Fälle aus.Fehler 502 in nginx + php5-fpm

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

In error.log von nginx ist dieser Fehler:

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

Bundesstaat php5-fpm in der Regel wie folgt aus:

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

denke ich, dies bedeutet Belastung nicht hoch ist.

Ich habe Backlog Params erhöht: in sysctl - net.core.somaconn = 5000, in php-fpm Pool - listen.backlog = 5000. Kein Effekt.

Ich zitiere eine Konfiguration:

/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; 

php-fpm Pool

[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 

Was kann ich tun, um dieses System zu optimieren und alle Serverressourcen zu nutzen?

PS. Es tut mir leid, mein Englisch ist schlecht.

+2

ich auf Ubuntu bin 13.10 und die Protokollierung von php5-fpm falsche Darstellung ist irgendwie, was tatsächlich passiert ..., die Logs sagten nichts :) Ich habe den Fehler gefunden, indem ich den Daemon direkt von der Kommandozeile aus gestartet habe, 'sudo php5-fpm - -daemonize --fpm-config/etc/php5/fpm/php-fpm.conf' – benjaoming

+7

nur für den Fall, dass jemand nach php-fpm Pool-Datei sucht, ist es in /etc/php5/fpm/pool.d/www.conf on Ubuntu 12.04.3 LTS –

+0

Für diejenigen, die zu dieser Frage durch googlen kommen: Versuchen Sie diese Lösung zuerst: http://StackOverflow.com/Questions/23443398/Gninx-error-connect-to-php5-fpm-sock-failed-13 -permission-denied – Alexar

Antwort

102

Das Problem ist Socket selbst, seine Probleme auf Hochlastfälle ist bekannt. Bitte beachten Sie mit TCP \ IP-Verbindung statt Unix-Socket, für dass Sie diese Änderungen vornehmen müssen:

  • in php-fpm Pool-Konfigurationlisten = /var/run/php5-fpm.sock ersetzen mit listen = 127.0.0.1:7777
  • in /etc/nginx/php_location ersetzen fastcgi_pass unix:/var/run/php5-fpm.sock; mit fastcgi_pass 127.0.0.1:7777;
+0

Zuvor war es einfach so - TCP/IP-Socket wurde verwendet. Aber die Situation war die gleiche. Ich probiere den TCP/IP Socket nochmal - werde sehen, was es uns gibt. – andre487

+2

Jetzt ist viel besser. Außerdem möchte ich sagen, dass Update PHP auf Version 5.4 sehr gute Wirkung hat. – andre487

+0

Ja, es ist weg. nginx wird auf Version 1.1.19 aktualisiert. Ich dachte über Caching auf Nginx, aber in der aktuellen Anwendung wird es nicht sinnvoll. – andre487

-6

ich das gleiche Problem, aber ich wünschte, nicht von Sockets TCP/IP zu wechseln. Ein Neustart von php-fpm und nginx löst das Problem.

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

Das Neustarten der Anwendung, wenn ein Problem auftritt, kann niemals als Lösung betrachtet werden. – GeekRide

+0

Abhängig von der Häufigkeit des Problems und der Menge der zuweisbaren Ressourcen - ja, es kann eine Lösung sein. Der grundlegende Punkt, dass * Systeme besser entworfen werden sollten * bleibt natürlich –

+0

@GeekRide, wenn die Situation die Verwendung einer Socket-Verbindung forderte, dann, wie DmitryV erklärte, "seine Probleme bei Hochlastfällen sind bekannt", würden wir haben keine andere Wahl, als den Dienst strategisch neu zu starten. Ich finde es traurig, dass so viele Leute dies übersehen, weil sie in Umgebungen mit niedrigeren Produktionskosten arbeiten. –

2

auf CentOS 7, Plesk 12.5

hatte ich dieses Problem nach meiner Festplatte voll ging und einige Dienste fehlgeschlagen. Andere Domains funktionierten perfekt, aber keiner von ihnen gab mir nur 502 und ähnliche Timeouts. Aus dem Errorlog:

[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 

es zu lösen, musste ich php-fpm und nginx (erster Platz und dann machen) Neustart - dann dieser Fehler verschwunden!

0

Der einzige Grund für diese Datei ist nicht erstellte Konfiguration auf /etc/php-fpm.d/www.conf

ändern hören = 127.0.0.1:9000

hören Mit =/var/run /php-fpm/php-fpm.sock

und beide starten nginx und php-fpm

+0

Ich habe diese Zeile, beide neu gestartet, aber die Datei ist immer noch nicht da. Keine Fehler in php5-fpm.log – Alecz