nginx mit php5-fpm upstream timed out (110: Connection timed out) while connecting to upstream
Wir haben ein web-server laufen mit nginx mit php5-fpm, apc setup.
Aber wir erfahren upstream-Verbindung timeout-Fehlern und slow downs beim Seitenaufbau seit kurzem. Eine schnelle php5-fpm restart das problem behoben, aber wir konnten die Ursache nicht finden.
Wir haben einen anderen web-server mit apache2 unter einer anderen subdomain, die Verbindung der gleichen Datenbank, tun genau die gleiche Arbeit. Aber die slow-downs auftreten, nur auf die nginx-fpm server.
Ich denke, das php5-fpm oder apc können die Probleme verursachen.
Protokolle sagen, dass die verschiedenen Verbindungs-time-outs:
upstream timed out (110: Connection timed out) while connecting to upstream bla bla bla
Den php5-fpm log zeigt nichts an. Nur Kind beginnt und endet:
Apr 07 22:37:27.562177 [NOTICE] [pool www] child 29122 started
Apr 07 22:41:47.962883 [NOTICE] [pool www] child 28346 exited with code 0 after 2132.076556 seconds from start
Apr 07 22:41:47.963408 [NOTICE] [pool www] child 29172 started
Apr 07 22:43:57.235164 [NOTICE] [pool www] child 28372 exited with code 0 after 2129.135717 seconds from start
Server wurde nicht geladen, wenn der Fehler aufgetreten ist, und laden Sie avg wurde nur 2 (2cpus 16cores) und die php5-fpm Prozesse schien einwandfrei zu funktionieren.
nginx conf:
user www-data;
worker_processes 14;
pid /var/run/nginx.pid;
# set open fd limit to 30000
worker_rlimit_nofile 30000;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
gzip_disable "msie6";
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
nginx aktiviert Website conf:
location ~* \.php$ {
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_pass backend;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_intercept_errors off;
fastcgi_ignore_client_abort off;
fastcgi_connect_timeout 20;
fastcgi_send_timeout 20;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
}
## Disable viewing .htaccess & .htpassword
location ~ /\.ht {
deny all;
}
}
upstream backend {
server 127.0.0.1:9000;
}
fpm conf:
pm.max_children = 500
pm.start_servers = 100
pm.min_spare_servers = 50
pm.max_spare_servers = 100
pm.max_requests = 10000
Gibt es Notfall-Neustart-Einstellungen in fpm conf-Datei.
Ich weiß nicht, ob Sie uns helfen, das Problem zu beheben?
emergency_restart_interval = 0
sicher. listen = 127.0.0.1:9000
InformationsquelleAutor faraklit | 2011-04-07
Du musst angemeldet sein, um einen Kommentar abzugeben.
Erstens, reduzieren Sie die PHP-FPM
max_requests
100; Sie wollen PHP-threads zu starten viel früher als 10000 req.Zweitens, Sie haben nur einen PHP-Prozess läuft mit vielen Kindern. Dies ist gut für die Entwicklung, aber in der Produktion Sie wollen mehr PHP-Prozesse mit jeweils weniger Kinder, so dass, wenn dieser Prozess ausfällt aus irgendeinem Grund, es gibt andere, die können die Flaute. Also, anstatt einem Verhältnis von 1:50, wie Sie jetzt haben, gehen Sie für ein Verhältnis von 10:5. Dies wird viel stabiler.
Dies zu erreichen, möchten Sie vielleicht, zu betrachten, so etwas wie supervisor verwalten Sie Ihre PHP-Prozesse. Wir verwenden diese in der Produktion und es hat wirklich geholfen, erhöhen unsere Verfügbarkeit und reduzieren die Menge der Zeit verbringen wir damit, die Verwaltung/überwachung der Server. Hier ist ein Beispiel für unsere config:
/etc/php5/php-fpm.conf:
/etc/supervisor.d/php-fpm.conf:
/etc/nginx/conf/php.backend:
EDIT:
Wie bei allen server-set-ups, verlassen Sie sich nicht auf Vermutung-Arbeit auf die Spur, wo Ihre Probleme sind. Ich empfehle die Installation von Munin zusammen mit den verschiedenen PHP (FPM) und Nginx plugins; diese wird Ihnen helfen, verfolgen schwer, Statistiken über die Anträge, Reaktionszeiten, Speicher-Nutzung, Festplatten-Zugriffe, thread - /Prozess-Ebenen... alle wesentlichen beim tracking nach unten, wo die Probleme sind.
Darüber hinaus, wie ich bereits erwähnt in einem Kommentar, hinzufügen von server - und client-side caching, um Ihre set-up, auch auf bescheidenem Niveau, kann helfen, eine bessere Erfahrung für die Nutzer, ob es mit nginx native-caching unterstützt oder etwas konkretes wie varnishd. Auch die meisten dynamischen Websites/apps haben viele statische Elemente können im Speicher gehalten werden & schneller bedient. Für diese aus dem cache kann helfen, verringern Sie die Last insgesamt und sicherzustellen, dass diejenigen Elemente, die unbedingt brauchen, um dynamische haben alle Ressourcen, die Sie benötigen, wenn Sie Sie brauchen.
Sie nicht benötigen, sollten Sie einen separaten server für die PHP-Verarbeitung wenn Sie mit nginx+php-fpm; tweaking nginx/php und das caching mit varnishd wird sehr viel produktiver sein werden. PHP funktioniert besser, wenn es kurzlebig; das ist, was es konzipiert ist, also ein Neustart ist eine gute Sache. APC sollte nicht betroffen sein. Und vergessen Sie nicht, akzeptieren Sie die Antwort, wenn es hilfreich war! 😉
numprocs=10 10 Prozesse teilen sich die gleiche APC-shm? und über die tcp-Problem, was, wenn es erforderlich ist, um zu dienen, zu viele Seiten (10-20M pro/Tag)? Sicher, ich werde annehmen, sobald ich versuche, und es löst unser problem. 😉
Ich wirklich nicht Sorge über APC; mehr procs kann bedeuten, mehr Speichernutzung, aber das ist in Ordnung, da Sie mehr Seiten erfolgreich! Wie für PHP das sterben; PHP hat ein hartes limit von max 250 req ' s gebaut. Wir haben festgestellt, dass wenn PHP erreicht das hard-limit kann es oft zu akzeptieren reqs beim recycling, dass diejenigen reqs zu hängen/fail. Die Absenkung der Grenze behebt das Problem, zusammen mit dem geben nginx mehrere backends, welches es ermöglicht den Failover zu einem anderen backend - /proc-wenn es nicht eine Antwort in einer fristgerechten Weise. Versuchen Sie es; überwachen der Ergebnisse mit Munin + nginx/fpm plugins & vergleichen Sie mit Ihrer aktuellen setup.
Auch, wenn Sie besorgt sind über den Dienst von 10-20 Seiten pro Tag, Sie WIRKLICH sollte das caching der Hölle aus der Sie alles, was Sie können mit varnishd. PHP+APC kommt nicht überall in der Nähe der Durchsatz Lack erzielen kann, sogar mit kurzlebigen cache-Zeiten; die BBC iPlayer website-caches die Seiten für eine sehr kurze Zeit (1-5 Minuten), aber selbst dieses bescheidene Niveau der Zwischenspeicherung ergibt sich eine enorme Reduktion der Last auf Ihrem Server. Mit einem klugen/aggressive caching-Strategie, die Sie könnte leicht dazu führen, dass die Ebenen, die Sie erwähnen, die mit bescheidenen hardware-setup. Caching-es ist die Zukunft!
InformationsquelleAutor Phillip B Oldham