- Mitglied seit
- 05. Jan 2012
- Beiträge
- 64
- Punkte für Reaktionen
- 0
- Punkte
- 6
Ich versuche seit Monaten ein sehr ärgerliches Problem zu lösen:
Sporadisch, d.h. mehrmals täglich, sind die Webserver-Dienste (z.B. Wordpress, Owncloud, ...) für mehrere Minuten (2-30min.) nicht erreichbar. Wird z.B. die Wordpress-Seite im Browser aufgerufen, dann wird das SSL-Zertifikat ausgetauscht und die sichere Verbindung aufgebaut aber die Wordpress Seite nicht angezeigt. Der Browser bleibt minutenlang mit einer leeren Seite und dem "Laden" Donut stehen. Es kommt jedoch keine Fehlermeldung wie z.B. "der Server antwortet nicht...". Die DSM Oberfläche ist hingegen problemlos zu erreichen und der Server langweilt sich.
Nach vielen Stunden Analyse habe ich scheinbar die Ursache gefunden. Immer wenn das Problem auftritt steht im PHP-FPM Logfile ("cat /var/log/php-fpm.log") folgendes:
Ein Reset von PHP-FPM ("/usr/syno/sbin/synoservicectl --restart php-fpm") löst das Problem temporär.
Bei Überschreitung der max. Anzahl von Kindsprozessen werden neue PHP-Anfragen anscheinend erst wieder bedient, wenn wieder ein neuer Kindsprozess gestartet werden kann.
Die Anzahl der PHP-FPM Kindsprozesse kann man nicht direkt in "/etc/php/php-fpm.conf" ändern da Synology diese im Startskript setzt.
Ich habe daher im Startskript "/etc/init/php-fpm.conf" die Zahl 20 zunächst durch 40 und jetzt sogar durch 60 ersetzt. Mit 60 taucht das Problem jetzt nur noch sehr selten auf, bisher nur einmalig in 5 Tagen.
Ich synchronisiere Emails eines Benutzers mit einem iPhone, einem iPad und einem MacBook. Zusätzlich synchronisiere ich den Kalender eines zweiten Benutzers mit zwei iPhones und einem iPad.
Auf Z-Push als Verursacher der vielen PHP-Kindsprozesse bin ich gestossen nachdem ich in der php-fpm.conf Datei "request_terminate_timeout = 600" ergänzt habe. Dann wurden ständig Kindsprozesse abgebrochen mit dem Hinweis auf z-push. Eine Internetrecherche hat ergeben, dass Z-Push long polling verwendet und Verbindungen bis zu 1h aufrecht erhält. Mit "request_terminate_timeout = 3600" wird keine Verbindung mehr abgebrochen.
Das Problem habe ich bereits seit vielen Monaten und mit mehreren Zarafa/Z-Push Versionen. Aktuell verwende ich das Zarafa-Paket 0.6.0 und Z-Push 2.1.3.
Die z-push-error.log zeigt keine Auffälligkeiten. Die z-puh.log zeigt jedoch, dass allein das eine iPhone bis zu 11x in einer Stunde (in unregelmässigen Abständen) einen Ping für Emails und 4x für den Kalender schickt.
Ich frage mich daher, ob dieses Verhalten richtig ist oder ob hier ein Bug innerhalb von z-push vorliegt. Synology berechnet die Anzahl der Kindsprozesse mit Hilfe einer Formel und hat diese bestimmt nicht sinnlos auf 20 begrenzt. Im Internet finden sich Anleitungen bei denen sich die Anzahl nach dem zur Verfügung stehenden Hauptspeicher und dem max. Speicherbedarf eines Kindsprozesses richtet. Demnach wären 60 bei mir bereits zu viel. Jedoch habe ich festgestellt, dass ein z-push Kindsprozess lediglich ein drittel des max. beobachteten Speicherbedarfs anderer Kindsprozesse belegt (ca. 15 Mbyte). Daher stellen bei mir 60 kein Problem dar. Bei DiskStations mit weniger Hauptspeicher jedoch schon.
Frage an alle ZARAFA Nutzer:
Ich wäre sehr daran interessiert, ob andere auch die Warnung "server reached max_children setting" in der php-fpm.log stehen haben.
Daher meine Bitte, dies wie folgt zu prüfen und hier zu berichten:
Wenn dieses Problem auch noch andere haben dann werde ich im ZARAFA bzw. Z-Push Forum um Unterstützung bitten.
Sporadisch, d.h. mehrmals täglich, sind die Webserver-Dienste (z.B. Wordpress, Owncloud, ...) für mehrere Minuten (2-30min.) nicht erreichbar. Wird z.B. die Wordpress-Seite im Browser aufgerufen, dann wird das SSL-Zertifikat ausgetauscht und die sichere Verbindung aufgebaut aber die Wordpress Seite nicht angezeigt. Der Browser bleibt minutenlang mit einer leeren Seite und dem "Laden" Donut stehen. Es kommt jedoch keine Fehlermeldung wie z.B. "der Server antwortet nicht...". Die DSM Oberfläche ist hingegen problemlos zu erreichen und der Server langweilt sich.
Nach vielen Stunden Analyse habe ich scheinbar die Ursache gefunden. Immer wenn das Problem auftritt steht im PHP-FPM Logfile ("cat /var/log/php-fpm.log") folgendes:
Rich (BBCode):
WARNING: [pool www] server reached max_children setting (20), consider raising it
Ein Reset von PHP-FPM ("/usr/syno/sbin/synoservicectl --restart php-fpm") löst das Problem temporär.
Bei Überschreitung der max. Anzahl von Kindsprozessen werden neue PHP-Anfragen anscheinend erst wieder bedient, wenn wieder ein neuer Kindsprozess gestartet werden kann.
Die Anzahl der PHP-FPM Kindsprozesse kann man nicht direkt in "/etc/php/php-fpm.conf" ändern da Synology diese im Startskript setzt.
Ich habe daher im Startskript "/etc/init/php-fpm.conf" die Zahl 20 zunächst durch 40 und jetzt sogar durch 60 ersetzt. Mit 60 taucht das Problem jetzt nur noch sehr selten auf, bisher nur einmalig in 5 Tagen.
Ich synchronisiere Emails eines Benutzers mit einem iPhone, einem iPad und einem MacBook. Zusätzlich synchronisiere ich den Kalender eines zweiten Benutzers mit zwei iPhones und einem iPad.
Auf Z-Push als Verursacher der vielen PHP-Kindsprozesse bin ich gestossen nachdem ich in der php-fpm.conf Datei "request_terminate_timeout = 600" ergänzt habe. Dann wurden ständig Kindsprozesse abgebrochen mit dem Hinweis auf z-push. Eine Internetrecherche hat ergeben, dass Z-Push long polling verwendet und Verbindungen bis zu 1h aufrecht erhält. Mit "request_terminate_timeout = 3600" wird keine Verbindung mehr abgebrochen.
Das Problem habe ich bereits seit vielen Monaten und mit mehreren Zarafa/Z-Push Versionen. Aktuell verwende ich das Zarafa-Paket 0.6.0 und Z-Push 2.1.3.
Die z-push-error.log zeigt keine Auffälligkeiten. Die z-puh.log zeigt jedoch, dass allein das eine iPhone bis zu 11x in einer Stunde (in unregelmässigen Abständen) einen Ping für Emails und 4x für den Kalender schickt.
Ich frage mich daher, ob dieses Verhalten richtig ist oder ob hier ein Bug innerhalb von z-push vorliegt. Synology berechnet die Anzahl der Kindsprozesse mit Hilfe einer Formel und hat diese bestimmt nicht sinnlos auf 20 begrenzt. Im Internet finden sich Anleitungen bei denen sich die Anzahl nach dem zur Verfügung stehenden Hauptspeicher und dem max. Speicherbedarf eines Kindsprozesses richtet. Demnach wären 60 bei mir bereits zu viel. Jedoch habe ich festgestellt, dass ein z-push Kindsprozess lediglich ein drittel des max. beobachteten Speicherbedarfs anderer Kindsprozesse belegt (ca. 15 Mbyte). Daher stellen bei mir 60 kein Problem dar. Bei DiskStations mit weniger Hauptspeicher jedoch schon.
Frage an alle ZARAFA Nutzer:
Ich wäre sehr daran interessiert, ob andere auch die Warnung "server reached max_children setting" in der php-fpm.log stehen haben.
Daher meine Bitte, dies wie folgt zu prüfen und hier zu berichten:
Rich (BBCode):
vi /var/log/php-fpm.log
/max_children
:q
Wenn dieses Problem auch noch andere haben dann werde ich im ZARAFA bzw. Z-Push Forum um Unterstützung bitten.
Zuletzt bearbeitet: