Numero di connessioni memcache non scende mai, continua a crescere

Question

Abbiamo configurato tre server Memcache per la nostra applicazione web.

Due stanno andando bene, gestendo decine di migliaia di letture e scritture, il tutto senza mantenere più di 12 connessioni ciascuna (secondo memcache-top).

Abbiamo un terzo server memcache che è responsabile per l'archiviazione dei dati di sessione client di gestione (utilizzando PHPs built in memcache session handler) e alcuni dati dell'applicazione casuali. Per qualche ragione il numero di connessioni su questa scatola non diminuisce mai, aumentando solo nel tempo. Ad esempio, abbiamo recentemente riavviato il server e un'ora più tardi memcache-top registra ~ 300 connessioni.

Il code base utilizza una combinazione di connessioni persistenti e connessioni dinamiche, ma non sono riuscito a trovare un semplice esempio per ricreare la situazione in cui le connessioni non muoiono mai. Questo terzo server memcache in realtà ospita la parte meno attivo della nostra applicazione web, come si può vedere da memcache-top:

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 

Quindi la mia domanda è: Perché i collegamenti per questa istanza memcache non muoiono mai?

Answer 1

Le connessioni persistenti in PHP allocheranno una connessione per ogni processo di lavoro di apache. L'installazione di Apache è in grado di consentire ~ 354 processi di lavoro?

Answer 2

A cosa sono impostati session.gc_probability e session.gc_divisor? Alcune distribuzioni Linux sovrascrivono questi valori e aggiungono un cronjob per cancellare le sessioni. Il tuo problema potrebbe essere causato da questo comportamento.

Answer 3

Stai utilizzando PHP5? Molto probabilmente sì. Ecco una possibile trappola dalla PHP session_set_save_handler documentation:

Dal PHP 5.0.5 la scrittura e chiudere gestori sono chiamati dopo oggetto distruzione e quindi non può utilizzare oggetti o generare eccezioni. I distruttori di oggetti possono tuttavia utilizzare le sessioni .

E 'possibile chiamare session_write_close() dal distruttore per risolvere questo problema di pollo e uovo.

Quanto vuoi scommettere che il gestore di sessione memcache non è stato rivisitato da prima di questo cambiamento? Come soluzione o almeno diagnostica, ti consiglio di scrivere le tue sessioni memcached aperte/chiudi/leggi/scrivi e distruggi le funzioni (non oggetto), collegale con session_set_save_handler e salta usando quello integrato. Per lo meno sarai in grado di registrare gli interni allora.