Archiv verlassen und diese Seite im Standarddesign anzeigen : nginx HTTP ERR 504 Gateway Time Out
Moin Leute,
wir haben seit kurzem den Apache in Rente geschickt und setzen jetzt auf nginx.
Jedoch erhalten wir sporadisch und auch nur für einige Sekunden folgende Fehlermeldungen:
504 Gateway Time Out
502 Bad Gateway
nginx 1.3.0 mit php5-fpm als FastCGI Schnittstelle zu php setzen wir ein.
Weiß jemand einen Rat?
Naja, entweder sind deine Konfigs zu großzügig oder zu knapp bemessen.
Die Fehlermeldungen kommen wenn der Server überlastet ist (zuwenig erlaubte Verbindungen/Serverprozesse), oder wenn sich die Einstellungen gegenseitig behindern.
Wie ist denn das Aufkommen bei dir so? Also wieviele Requests hast du denn so pro Minute?
Kannst ja mal deine nginx.conf und php-fpm.conf zeigen.
Die Werte die reinspielen sind:
- worker_processes
- worker_rlimit_nofile
- worker_connections
- pm.max_children
- pm.start_servers
- pm.min_spare_servers
- pm.max_spare_servers
- pm.max_requests
Würde dir vorschlagen erst einmal niedrig anzufangen und dich dann langsam hochzuarbeiten, je nachdem wie das Seitenverhalten ist.
Ich habe bei mir (ca 30k Requests/min) folgendes und fahre gut damit:
- worker_processes 4
- worker_rlimit_nofile 50000
- worker_connections 20000
- pm.max_children 150
- pm.start_servers 5
- pm.min_spare_servers 1
- pm.max_spare_servers 10
- pm.max_requests 50
Aber jeder Server reagiert anders, andere Einstellungen können das Verhalten auch noch beeinflußen. Einfach probieren...
Ich habe für meine Einstellungen etwa 2 Tage gebraucht, bis es wirklich keine Probleme mehr gab. Aller Anfang ist schwer ;)
kann man das irgendwo nachlesen wieviel Requeste man pro min hat?
netstat... access.logs...
In 90% der Fälle deuten die fehlercodes darauf hin das die fast cgi schnittstelle nicht reagiert und somit kein php ausgeführt wird.
Du hast bestimmt nen cron der den fast cgi startet/checked ob er noch läuft? Die sporadischen ausfälle sind bestimmt in dem Zeitfenster wo der cron nicht läuft und fastCGI nicht reagiert weil der prozess nicht läuft.
Die Probleme hatte ich leider auch mal ... könntest testweise mal den cron von der Taktung hochschrauben um zu testen ob es daran liegt. Ist ja nur ne prozess suche und wenn nichts gefunden wird einfach den fastCGI respawnen.
Best regards,
DefCon3
nein es lag wohl einfach nur an einer config mit der nginx und php5-fpm nicht harmonierten
gestern ne neue Config eingespielt zum testen und seit dem keine 502 Error lt Log
In 90% der Fälle deuten die fehlercodes darauf hin das die fast cgi schnittstelle nicht reagiert und somit kein php ausgeführt wird.
Du hast bestimmt nen cron der den fast cgi startet/checked ob er noch läuft? Die sporadischen ausfälle sind bestimmt in dem Zeitfenster wo der cron nicht läuft und fastCGI nicht reagiert weil der prozess nicht läuft.
Soetwas braucht man seid der Version 0.x.y nicht mehr, diese Zeiten sind vorbei.
Gut zu wissen :) War immer nen derber Aufwand
Manche Leute nutzen sogar Apache2 als backend und Nginx als Frontendlösung. Hab ich schon bei einigen Amerikanischen Trackern mit weit über 500k Peers gesehen.
Manche Leute nutzen sogar Apache2 als backend und Nginx als Frontendlösung. Hab ich schon bei einigen Amerikanischen Trackern mit weit über 500k Peers gesehen.
Die Lösung ist allerdings mehr als sinnfrei. Solange die Webanwendung nicht direkt von Apachemodulen abhängt, ist eine Kombination von nginx und Apache Quatsch. Kann man die Webanwendung nicht entsprechend anpassen, ist es natürlich komfortabel nginx vor den Apachen zu schalten, um den Server zu entlasten und die Seite zu beschleunigen.
Meines Wissens benötigt keine Trackersource zwingend den Apachen oder eines seiner Module, daher verstehe ich die Kombination nicht. nginx allein bietet noch mehr Performance, ist resistenter und hat weniger Lücken.
etwas OT...
Ich habe bei einigen Gesprächen mit Betreibern größerer Non-DE-ALTs festgestellt, dass auch da wenig Zeit in Optimierung investiert wird. Deren Server haben HW verbaut, die man hierzulande für sehr gutes Geld bekommt. Daher ist es auch kein Wunder, wenn die 600$ und mehr im Monat berappen müssen. Und dennoch kriechen die Server oft auf dem Zahnfleisch, auch wenn da nur 200k Peers zugegen sind (oder noch weniger). OK, "nur" - bei den meißten deutschen ALTs wäre da schon lange Schicht im Schacht oO
Mit meinem Server könnte ich 1Mio Peers bedienen - da wäre die Last zwar dauerhaft bei 90%, aber für 8GB und einen Xeon E3 ist das in Ordnung.
Mein Fazit: Optimiert eure Site, setzt nginx ein und ihr spart bares Geld. Eure User werden es euch danken ;)
hab vor ein paar tagen den server testweise mit apache laufen lassen...
CPU Last ging hoch auf 50-60% Ram Verbraucht ging auf mehrere GB Hoch
danach mit nginx:
CPU Last: 4-10% Ramverbrau unter 1GB
und das bei 26000 Peers in der Primetime
Meiner braucht bei knapp 20k Peers ca. 150mb Ram. CPU Last ist auch so um den dreh zwischen 4-10%.
Ich dachte schon ich habe eine Krücke als Server, aber wenn ihr mit nginx bei den Peerzahlen schon solche Stats habt, dann habt ihr die Krücke *gg*
Ist auch nicht nötig. Ich bestelle immer dann einen besseren Server wenn ich ihn brauche.
Ich bestelle immer dann einen besseren Server wenn ich ihn brauche.
Für einen Tracker? Zuerst sollte man die Source und den Server optimieren, bevor man mehr Kohle rauswirft. Ist zumindest meine Meinung. Mein alter Server (2Gig, alter Pentium) hat 70k ausgehalten, mit Apache und PHP Announce. OK, die Last war nicht mehr feierlich, aber es ging ;)
Das eine schließt das andere nicht aus. ;)
Na gut, da hast du natürlich recht ;)
vBulletin® v3.8.9, Copyright ©2000-2024, vBulletin Solutions, Inc.