Soluzione 1:
Congratulazioni per avere un sito web popolare e riuscire a mantenerlo in esecuzione su una macchina virtuale per tutto questo tempo.
Se ottieni davvero due milioni di visualizzazioni di pagina al giorno, accumuli MOLTE sessioni PHP nel filesystem e ci vorrà molto tempo per eliminarle, indipendentemente dal fatto che tu usi fuser o rm o un aspirapolvere.
A questo punto ti consiglio di cercare modi alternativi per archiviare le tue sessioni:
- Un'opzione è memorizzare le sessioni in
memcached. È velocissimo, ma se il server si arresta in modo anomalo o si riavvia, tutte le tue sessioni vengono perse e tutti vengono disconnessi. - Puoi anche archiviare le sessioni in un database. Questo sarebbe un po' più lento di memcached, ma il database sarebbe persistente e potresti cancellare le vecchie sessioni con una semplice query SQL. Per implementarlo, però, devi scrivere un gestore di sessione personalizzato.
Soluzione 2:
Rimozione di fuser dovrebbe aiutare. Questo lavoro esegue un fuser comando (controlla se un file è attualmente aperto) per ogni file di sessione trovato, che può facilmente richiedere diversi minuti su un sistema occupato con 14k sessioni. Questo era un bug di Debian (Ubuntu è basato su Debian).
Invece di memcached puoi anche provare a usare tmpfs (un filesystem in memoria) per i file di sessione. Come memcached, questo invaliderebbe le sessioni al riavvio (questo può essere aggirato eseguendo il backup di questa directory da qualche parte nello script di arresto e ripristinando nello script di avvio), ma sarà molto più facile da configurare. Ma non aiuterà con fuser problema.
Soluzione 3:
Pertanto, le opzioni Memcached e di archiviazione delle sessioni del database suggerite dagli utenti qui sono entrambe buone scelte per aumentare le prestazioni, ognuna con i propri vantaggi e svantaggi.
Ma dai test delle prestazioni, ho scoperto che l'enorme costo delle prestazioni di questa manutenzione della sessione è quasi interamente dovuto alla chiamata a fuser nel cron job. Ecco i grafici delle prestazioni dopo il ripristino del cron job Natty / Oneiric che utilizza rm invece di fuser per tagliare le vecchie sessioni, il passaggio avviene alle 2:30.
Puoi vedere che il degrado periodico delle prestazioni causato dalla pulizia della sessione PHP di Ubuntu è quasi completamente rimosso. I picchi mostrati nel grafico delle operazioni su disco sono ora di entità molto inferiore e quasi quanto questo grafico può misurare, mostrando una piccola e breve interruzione in cui in precedenza le prestazioni del server erano notevolmente ridotte per 25 minuti. L'utilizzo extra della CPU è stato completamente eliminato, questo è ora un lavoro legato all'IO.
(un lavoro IO non correlato viene eseguito alle 05:00 e un lavoro CPU viene eseguito alle 7:40 che causano entrambi i propri picchi su questi grafici)
Il cron job modificato che sto eseguendo ora è:
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