Anzahl der Memcache-Verbindungen sinkt nie, wächst weiter

Question

Wir haben drei Memcache-Server für unsere Webanwendung eingerichtet.

Zwei sind in Ordnung, Umgang mit Zehntausenden von Lese-und Schreibvorgänge, alle unter Beibehaltung nicht mehr als 12 Verbindungen jeweils (nach memcache-top).

Wir haben einen dritten Memcache-Server, der für das Speichern von administrativen Clientsitzungsdaten (unter Verwendung von PHPs built in memcache session handler) und einigen zufälligen Anwendungsdaten verantwortlich ist. Aus irgendeinem Grund sinkt die Anzahl der Verbindungen auf dieser Box nie, sondern nimmt nur mit der Zeit zu. Zum Beispiel haben wir kürzlich den Server neu gestartet und eine Stunde später Memcache-Top-Datensätze ~ 300 Verbindungen.

Die Codebasis verwendet eine Mischung aus persistenten Verbindungen und dynamischen Verbindungen, aber ich konnte kein einfaches Beispiel für die Wiederherstellung der Situation finden, in der Verbindungen niemals abstürzen. Dieser dritte memcache Server beherbergt tatsächlich die am wenigsten aktiven Teil unserer Web-Anwendung, wie man es von memcache-top sehen:

memcache-top v0.6 (default port: 11211, color: on, refresh: 3 seconds) 

INSTANCE   USAGE HIT % CONN TIME EVICT/s READ/s WRITE/s 
memcache1:11211 15.7% 83.5% 10 1.2ms  0.0 24.9K 34.5K 
memcache2:11211 15.8% 81.3% 10 1.0ms  0.0 19.1K 31.6K 
memcache3:11211 0.1% 0.0% 354 1.1ms  0.0  4  321 

AVERAGE: 10.5% 55.0% 124 1.1ms 0.0 14.7K 22.1K 

TOTAL: 0.6GB/ 6.0GB 374 3.2ms 0.0 44.0K 66.4K 

Also meine Frage ist: Warum sind die Verbindungen für diese memcache Instanz noch nie sterben?

Answer 1

Persistente Verbindungen in PHP weisen eine Verbindung für jeden Apache-Worker-Prozess zu. Ist Apache so eingerichtet, dass ca. 354 Arbeitsprozesse möglich sind?

Answer 2

Was sind Ihre session.gc_probability und session.gc_divisor auf? Einige Linux-Distributionen überschreiben diese Werte und fügen einen Cronjob hinzu, um Sitzungen zu löschen. Ihr Problem kann durch dieses Verhalten verursacht werden.

Answer 3

Verwenden Sie PHP5? Höchstwahrscheinlich ja. Hier ist eine mögliche Gefahr von der PHP session_set_save_handler documentation:

Ab PHP 5.0.5 die Schreib- und schließen Handler nach Objekt Zerstörung genannt werden und daher nicht Objekte verwenden können, oder Ausnahmen auslösen. Die Objektdestruktoren können jedoch Sitzungen verwenden.

Es ist möglich, session_write_close() aus dem destructor zu nennen dieses Huhn und Ei-Problem zu lösen.

Wie viel möchten Sie wetten, dass der Memcache-Session-Handler seit dieser Änderung nicht erneut aufgerufen wurde? Als Lösung oder zumindest als Diagnose empfehle ich, eine eigene memcached Session zu schreiben, die open/close/read/write und destroy Funktionen (nicht object), mit session_set_save_handler verbindet und die eingebaute Session überspringt. Zumindest können Sie dann die Interna loggen.