Alle unsere Fehler werden in NewRelic protokolliert und wir haben immer einige Warnungen session_write_closeim Fehlerprotokoll gesehen. Die Fehlerrate ist jedoch gestiegen und überflutet jetzt unser 24-Stunden-Protokoll.
Unser Server ist stark ausgelastet und viele Benutzer sind gleichzeitig angemeldet. Die meisten dieser Benutzer sehen diese session_write_closeWarnungen nicht. Einige sehen sie schon, was es für uns fast unmöglich macht, die Ursache zu finden und zu beheben.
Dies ist die vollständige Fehlermeldung:
Error message
E_WARNING: session_write_close(): Failed to write session data (files).
Please verify that the current setting of session.save_path is correct
(/opt/php55/var/lib/php/session-nginx)
Also habe ich nachgeschaut, wie viele Dateien sich in diesem Verzeichnis befinden 9431und welche Rechte dafür gelten -rw------- 1 nginx nginx.
Ich sehe keinen Fehler an meiner Konfiguration, den Dateirechten usw.
Wir haben keine Optionen mehr. Was kann ich tun, um dieses Problem zu lösen? Derzeit betrifft es weniger als 1 % unserer Benutzer, wir möchten unsere Rate einfach so niedrig wie möglich halten.
Hier ist eine Liste meiner php.ini-Konfiguration.
Directive Local Value Master Value
session.auto_start Off Off
session.cache_expire 180 180
session.cache_limiter nocache nocache
session.cookie_domain no value no value
session.cookie_httponly Off Off
session.cookie_lifetime 0 0
session.cookie_path / /
session.cookie_secure Off Off
session.entropy_file /dev/urandom /dev/urandom
session.entropy_length 32 32
session.gc_divisor 1000 1000
session.gc_maxlifetime 1440 1440
session.gc_probability 1 1
session.hash_bits_per_character 5 5
session.hash_function 0 0
session.name PHPSESSID PHPSESSID
session.referer_check no value no value
session.save_handler files files
session.save_path /opt/php55/var/lib/php/session-nginx /opt/php55/var/lib/php/session-nginx
session.serialize_handler php php
session.upload_progress.cleanup On On
session.upload_progress.enabled On On
session.upload_progress.freq 1% 1%
session.upload_progress.min_freq 1 1
session.upload_progress.name PHP_SESSION_UPLOAD_PROGRESS PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.prefix upload_progress_ upload_progress_
session.use_cookies On On
session.use_only_cookies On On
session.use_strict_mode Off Off
session.use_trans_sid 0 0
Einige Serverstatistiken: CentOS 6.6 PHP 5.5.28 Nginx 1.6.2. Jede Hilfe ist willkommen!
Antwort1
Bei einem stark ausgelasteten Server würde ich memcached(vielleicht sogar redis?) zur Sitzungsspeicherung verwenden. Wenn ich in Ihrer Situation wäre, würde ich das also wahrscheinlich einfach so einrichten und dann sehen, ob das Problem zufällig verschwunden ist.
Ich würde auch nicht die Sitzungsgarbage Collection von PHP verwenden, die die Garbage Collection von Webanforderungsjobs abhält. Ich würde meinen eigenen Job einrichten, der das handhabt, entweder von Cron oder von einem Jobwarteschlangensystem aus.
Verfügen Sie bereits über eine Art Sitzungsbereinigungssystem außerhalb der Sitzungs-Garbage Collection von PHP?
Beträgt die Häufigkeit, mit der dies geschieht, 0,1 % der Zeit, was mit Ihrer Einstellung übereinstimmen würde session.gc_divisor?
Laufen Ihre PHP-Prozesse als Nginx-Benutzer? Es ist PHP und nicht Nginx, das die Bereinigung basierend auf den session.gc_*Einstellungen durchführt. Wenn PHP als Nginx ausgeführt wird, ist das gut im Hinblick auf den Zugriff auf die PHP-Sitzungsdateien, aber wahrscheinlich schlecht im Hinblick auf die gemeinsame Nutzung einer Benutzer-ID mit dem Nginx-Server.
Möglicherweise benötigen Sie die Ausführungsberechtigung für dieses Sitzungsverzeichnis, damit Ihre Garbage Collection sehen kann, was dort bereinigt werden muss.
Ich wäre auch besorgt, wenn Sie nicht session.save_pathetwas Spezifisches für Ihre Anwendung einstellen. Das würde bedeuten, dass, wenn Sie mehrere Anwendungen haben, die dasselbe Sitzungsverzeichnis gemeinsam nutzen, bei der Garbage Collection die App mit der kürzesten Ablaufzeit gewinnt und die Sitzungen der anderen App bereinigt.
Antwort2
Die offensichtliche Beobachtung, die ich aus Ihrer Frage gezogen habe, ist, dass Sie einen zu großen Engpass haben, wenn Sie versuchen, Dateien in /opt/php55/var/lib/php/session-nginx zu speichern. Ihre Lösung besteht also darin, den Engpass zu beseitigen, indem Sie zunächst diagnostizieren, was genau schief läuft.
Angenommen, es rast beim Schreiben auf die Festplatte und die Fehler sind ein Zeichen dafür, dass es aufgibt, würde ich Dmesg-Fehler erwarten, die Probleme beim Schreiben auf die Festplatte anzeigen. Wenn dies der Fall ist, können Sie in den Speicher schreiben oder andere Lösungen verwenden, die zu einer schnelleren „Festplatte“ führen.
mc0e erwähnt memcached anstelle von save_handle=files, das ist eine gute Option. Eine Alternative zu memcached könnte die Verwendung von tmpfs sein, das die Sitzung im Wesentlichen genauso in den Speicher legt (so dass es schnelle Schreibzeiten hat), aber keine neue App benötigt.
Ich würde auch die Frage stellen, welche Art von Dateisystem sich unter /opt/php55/var/lib/php/session-nginx befindet? Sie benötigen nicht das komplexe Journaling von ext3/4 für einen Vorgang, der im Grunde ein mktmp-ähnlicher Vorgang ist. Sie können einen Ordner in /tmp erstellen und ihn symbolisch verknüpfen, um den Overhead beim Erstellen von Dateien zu verringern.
Wie ist die Hardware-Konfiguration? Wenn es sich um eine einzelne Festplatte ohne Zwischenspeicherung handelt, sollten Sie Probleme in dmesg sehen, wenn Sie die Leistungsgrenze erreichen. Ich habe AMCC-Raid-Controller mit Raid-1 in allen meinen Servern verwendet. Wenn es Raid-1 (Spiegel) ist, ist das Lesen schnell, aber die Schreibgeschwindigkeit hängt davon ab, wie gut das Raid implementiert ist (ich weiß, dass AMCC Schreibvorgänge in Raid-1 auf Festplatten verteilen kann, aber nicht alle RAID-1-Implementierungen tun das, ich weiß, dass Software-Raid das nicht tut). Mein alter Chef hat aus diesem Grund auf Raid-5 geschworen, und solange es sich um echtes Hardware-Raid handelt (RAID-5 kann die CPU stark belasten, wenn es das nicht ist), wird das Ihren Festplattendurchsatz drastisch beschleunigen. Eine weitere Option ist eine Solid-State-Disk. Wenn Sie sich aber wirklich dafür entscheiden, würde ich die Verwendung von Memcached oder tmpfs vorschlagen, da mehr Speicher (im Vergleich zu anderer neuer Hardware) immer eine gute Idee ist.
Die einfachste Lösung besteht jedoch darin, /tmp/session-nginx zu erstellen und /opt/php55/var/lib/php/session-nginx zu /tmp/session-nginx/ zu verknüpfen oder einzubinden.
Antwort3
Ein Teil der Frage betrifft die Schwierigkeit, diese Art von Fehlern zu verfolgen. Dann schlage ich vor, die Sitzung Ihres Codes in einem Try/Catch-Block explizit zu schließen. Behandeln Sie die Ausnahme, gehen Sie in den Ruhezustand und versuchen Sie es erneut.
Der andere Teil der Frage beschreibt einen Schreibfehler, der zufälliger Natur zu sein scheint. Das ist nicht das, was ich von falschen Berechtigungen erwarte. Ich würde vermuten, dass Sie zu viele offene Dateien haben.
Es gibt ein paar Konfigurationen, die ich optimieren würde, um zu sehen, was passiert:
Erhöhen Sie das Limit der geöffneten DateienMöglicherweise ist in einem Teil Ihres Betriebssystems eine niedrigere Grenze festgelegt. Beispielsweise unterstützt mein Notebook Hunderttausende geöffnete Dateien, aber nur 4000 vom selben Benutzer.
Reduzieren Sie die Anzahl der Anfragen pro Kind auf 1000.Dadurch wird jeder HTTP-Server nach der Bedienung von 1000 Clients neu gestartet.
MaxClients reduzierenUndListenBacklog erhöhen. Das ist sehr, sehr kontraintuitiv, aber wenn Sie MaxClients/Servers zu hoch einstellen, werden viele Prozesse um Ressourcen auf Ihrem Server kämpfen und Engpässe verursachen. Das hängt stark von der Art der Engpässe ab, die Sie haben. Bei mir sind es die Datenbankserver.