Solution 1 :
Félicitations pour avoir un site Web populaire et avoir réussi à le faire fonctionner sur une machine virtuelle pendant tout ce temps.
Si vous tirez vraiment deux millions de pages vues par jour, alors vous allez empiler BEAUCOUP de sessions PHP dans le système de fichiers, et elles vont prendre beaucoup de temps à supprimer, que vous utilisiez ou non fuser ou rm ou un aspirateur.
À ce stade, je vous recommande de rechercher d'autres moyens de stocker vos sessions :
- Une option consiste à stocker les sessions dans
memcached. C'est rapide comme l'éclair, mais si le serveur plante ou redémarre, toutes vos sessions sont perdues et tout le monde est déconnecté. - Vous pouvez également stocker des sessions dans une base de données. Ce serait un peu plus lent que memcached, mais la base de données serait persistante et vous pourriez effacer les anciennes sessions avec une simple requête SQL. Pour implémenter cela, cependant, vous devez écrire un gestionnaire de session personnalisé.
Solution 2 :
Suppression de fuser devrait aider. Ce travail exécute un fuser commande (vérifier si un fichier est actuellement ouvert) pour chaque fichier de session trouvé, ce qui peut facilement prendre plusieurs minutes sur un système occupé avec 14 000 sessions. C'était un bogue de Debian (Ubuntu est basé sur Debian).
Au lieu de memcached, vous pouvez également essayer d'utiliser tmpfs (un système de fichiers en mémoire) pour les fichiers de session. Comme memcached, cela invaliderait les sessions au redémarrage (cela peut être contourné en sauvegardant ce répertoire quelque part dans le script d'arrêt et en le restaurant dans le script de démarrage), mais sera beaucoup plus facile à configurer. Mais cela n'aidera pas avec fuser problème.
Solution 3 :
Ainsi, les options de stockage Memcached et de session de base de données suggérées par les utilisateurs ici sont toutes deux de bons choix pour augmenter les performances, chacune avec ses propres avantages et inconvénients.
Mais en testant les performances, j'ai trouvé que l'énorme coût de performance de cette maintenance de session est presque entièrement dû à l'appel à fuser dans le travail cron. Voici les graphiques de performances après le retour au travail cron Natty / Oneiric qui utilise rm au lieu de fuser pour couper les anciennes sessions, le basculement a lieu à 2h30.
Vous pouvez voir que la dégradation périodique des performances causée par le nettoyage de session PHP d'Ubuntu est presque entièrement supprimée. Les pics affichés dans le graphique des opérations de disque sont désormais beaucoup plus petits et à peu près aussi minces que ce graphique peut éventuellement le mesurer, montrant une petite et courte interruption où les performances du serveur étaient auparavant considérablement dégradées pendant 25 minutes. L'utilisation supplémentaire du processeur est entièrement éliminée, il s'agit désormais d'un travail lié aux E/S.
(une tâche d'E/S non liée s'exécute à 05h00 et une tâche CPU s'exécute à 7h40, qui provoquent toutes deux leurs propres pics sur ces graphiques)
La tâche cron modifiée que j'exécute actuellement est :
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