Ubuntus Garbage-Collection-Cron-Job für PHP-Sitzungen dauert 25 Minuten, warum?

Lösung 1:

Herzlichen Glückwunsch, dass Sie eine beliebte Website haben und es geschafft haben, sie die ganze Zeit auf einer virtuellen Maschine am Laufen zu halten.

Wenn Sie wirklich zwei Millionen Seitenaufrufe pro Tag erzielen, werden Sie eine Menge PHP-Sitzungen im Dateisystem anhäufen, und es wird lange dauern, bis sie gelöscht werden, unabhängig davon, ob Sie fuser oder rm oder Staubsauger.

An dieser Stelle würde ich Ihnen empfehlen, nach alternativen Möglichkeiten zum Speichern Ihrer Sitzungen zu suchen:

• Eine Möglichkeit besteht darin, Sitzungen in memcached zu speichern . Das geht blitzschnell, aber wenn der Server abstürzt oder neu startet, gehen alle Ihre Sitzungen verloren und alle werden abgemeldet.
• Sie können Sitzungen auch in einer Datenbank speichern. Dies wäre etwas langsamer als Memcache, aber die Datenbank wäre persistent, und Sie könnten alte Sitzungen mit einer einfachen SQL-Abfrage löschen. Um dies zu implementieren, müssen Sie jedoch einen benutzerdefinierten Sitzungshandler schreiben.

Lösung 2:

Entfernung von fuser sollte helfen. Dieser Job führt fuser aus Befehl (überprüfen, ob gerade eine Datei geöffnet ist) für jede gefundene Sitzungsdatei, was auf einem ausgelasteten System mit 14.000 Sitzungen leicht mehrere Minuten dauern kann. Dies war ein Debian-Fehler (Ubuntu basiert auf Debian).

Anstelle von memcached können Sie auch versuchen, tmpfs (ein Dateisystem im Speicher) für Sitzungsdateien zu verwenden. Wie Memcached würde dies Sitzungen beim Neustart ungültig machen (dies kann umgangen werden, indem dieses Verzeichnis irgendwo im Shutdown-Skript gesichert und im Startskript wiederhergestellt wird), aber es ist viel einfacher einzurichten. Aber es wird nicht mit fuser helfen Problem.

Lösung 3:

Daher sind die von Benutzern hier vorgeschlagenen Speicheroptionen für Memcache- und Datenbanksitzungen beide eine gute Wahl zur Leistungssteigerung, jede mit ihren eigenen Vor- und Nachteilen.

Aber durch Leistungstests habe ich herausgefunden, dass die enormen Leistungskosten dieser Sitzungswartung fast ausschließlich auf den Aufruf von fuser zurückzuführen sind im Cronjob. Hier sind die Leistungsdiagramme nach der Rückkehr zum Cron-Job Natty / Oneiric, der rm verwendet statt fuser Um alte Sitzungen zu kürzen, erfolgt die Umschaltung um 2:30.

Sie können sehen, dass der periodische Leistungsabfall, der durch die PHP-Session-Bereinigung von Ubuntu verursacht wird, fast vollständig beseitigt wurde. Die im Diagramm „Festplattenvorgänge“ angezeigten Spitzen sind jetzt viel kleiner und ungefähr so ​​dünn, wie dieses Diagramm möglicherweise messen kann, und zeigen eine kleine, kurze Unterbrechung, bei der die Serverleistung zuvor 25 Minuten lang erheblich beeinträchtigt war. Zusätzliche CPU-Auslastung wird vollständig eliminiert, dies ist jetzt ein IO-gebundener Job.

(Ein unabhängiger IO-Job läuft um 05:00 Uhr und ein CPU-Job läuft um 7:40 Uhr, die beide ihre eigenen Spitzen in diesen Diagrammen verursachen)

Der modifizierte Cron-Job, den ich jetzt ausführe, ist:

09 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && \
   [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 \
   -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 \
   | xargs -n 200 -r -0 rm