Solución 1:
Felicitaciones por tener un sitio web popular y lograr mantenerlo funcionando en una máquina virtual durante todo este tiempo.
Si realmente está obteniendo dos millones de páginas vistas por día, entonces acumulará MUCHAS sesiones de PHP en el sistema de archivos, y tomará mucho tiempo eliminarlas sin importar si usa fuser o rm o una aspiradora.
En este punto, te recomiendo que busques formas alternativas de almacenar tus sesiones:
- Una opción es almacenar sesiones en
memcached. Esto es muy rápido, pero si el servidor falla o se reinicia, todas sus sesiones se pierden y todos se desconectan. - También puede almacenar sesiones en una base de datos. Esto sería un poco más lento que Memcached, pero la base de datos sería persistente y podría borrar sesiones antiguas con una simple consulta SQL. Sin embargo, para implementar esto, debe escribir un controlador de sesión personalizado.
Solución 2:
Eliminación de fuser debería ayudar. Este trabajo ejecuta un fuser comando (compruebe si un archivo está abierto actualmente) para cada archivo de sesión encontrado, lo que puede llevar fácilmente varios minutos en un sistema ocupado con 14k sesiones. Este fue un error de Debian (Ubuntu está basado en Debian).
En lugar de memcached, también puede intentar usar tmpfs (un sistema de archivos en la memoria) para los archivos de sesión. Al igual que memcached, esto invalidaría las sesiones al reiniciar (esto se puede solucionar haciendo una copia de seguridad de este directorio en algún lugar del script de apagado y restaurando en el script de inicio), pero será mucho más fácil de configurar. Pero no ayudará con fuser problema.
Solución 3:
Por lo tanto, las opciones de almacenamiento de sesión de base de datos y Memcached sugeridas por los usuarios aquí son buenas opciones para aumentar el rendimiento, cada una con sus propias ventajas y desventajas.
Pero mediante pruebas de rendimiento, descubrí que el enorme costo de rendimiento del mantenimiento de esta sesión se debe casi por completo a la llamada a fuser en el trabajo cron. Aquí están los gráficos de rendimiento después de volver al trabajo cron Natty / Oneiric que usa rm en lugar de fuser para recortar sesiones antiguas, el cambio se produce a las 2:30.
Puede ver que la degradación periódica del rendimiento causada por la limpieza de la sesión de PHP de Ubuntu se elimina casi por completo. Los picos que se muestran en el gráfico de operaciones de disco ahora son mucho más pequeños en magnitud y tan delgados como este gráfico puede medir, mostrando una interrupción pequeña y breve donde anteriormente el rendimiento del servidor se degradó significativamente durante 25 minutos. El uso adicional de la CPU se elimina por completo, ahora es un trabajo vinculado a IO.
(un trabajo de E/S no relacionado se ejecuta a las 05:00 y el trabajo de la CPU se ejecuta a las 7:40, lo que provoca sus propios picos en estos gráficos)
El trabajo cron modificado que estoy ejecutando ahora es:
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