Discussion :

[matdam]

Bonjour,

N'ayant trouvé nulle trace de ce problème sur la toile, je viens faire appel à vos lumières.

Le contexte:
Je dispose d'un environnement Linux (Ubuntu server), Apache2, MySQL, PHP5. Le nettoyage des fichiers de session obsolète se fait via un cron mis en place à l'installation de php5 (cron.d/php5) et qui s'execute toutes les demis heure. Apache est configuré en mode prefork avec un ServerLimit + MaxClient égal à 900. Le site hébergé a un trafic relativement élevé (250k-300k visites quotidiennes).

Le problème:
Lorsque le cron qui nettoie les fichiers de session du repertoire /var/lib/php5 s'execute, il occupe l'ensemble des "slots" d'apache encore disponible et fait tomber le serveur pendant les 3-4 minutes que dure le nettoyage. Ce n'est pas admissible.

Solutions envisagées:
- Augmenter le ServerLimit et le MaxClient, ce qui ne change rien au probleme, s'il est fixé à 2000, les 2000 process seront occupés, etc.
- Supprimer l'ensemble des fichiers de session par cron la nuit, temps d'indisponibilité plus long (rm 2-3 millions de fichiers..), mais une seule fois par jour. C'est la solution adoptée actuellement en désespoir de cause.


Merci d'avance pour vos réponses.

[_Mac_]

Pas compris : ton cron fait un appel HTTP avec wget par exemple sur Apache pour exécuter un script PHP5 ?

[matdam]

le cron n'est pas un ajout personnel, c'est un fichier généré à l'installation de php5 qui est chargé de supprimer les vieilles sessions.
Il fait juste une comparaison avec le gc_maxlifetime du php.ini et la valeur par defaut et se base sur la plus élevée.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
# /etc/cron.d/php5: crontab fragment for php5
# This purges session files older than X, where X is defined in seconds
# as the largest value of session.gc_maxlifetime from all your php.ini
# files, or 24 minutes if not defined. See /usr/lib/php5/maxlifetime
 
# Look for and purge old sessions every 30 minutes
09,39 * * * * root [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm

Je ne comprend justement pas pourquoi son execution à ces effets là...
Son action mobiliserait les ressources du serveur ce qui l'empecherait de repondre aux requetes HTTP, donc celles-ci s'accumuleraient en wait?
Avec un core i7 et 12go de ram ça me parait peu probable


Pensez vous qu'il est judicieux de passer en mode worker avec un proc multicore (le i7 4 coeurs physique, 4 virtuels)

[_Mac_]

Honnêtement, je ne pense pas que modifier la configuration d'Apache change grand-chose au problème. Tu peux toujours essayer mais Apache n'est pas sollicité avec ce cron.

A mon avis, il faut analyser plus dans le détail ce qu'il se passe sur le système au moment où le script passe : utilisation CPU, I/O, mémoire.

C'est indispensable de faire tourner ce script toutes les 30 minutes ? Il ne pourrait pas tourner une seule fois la nuit quand il n'y a plus personne sur le site ?

[matdam]

C'est la solution adoptée pour l'instant, il vide le repertoire de session une fois par nuit, mais ça ne regle pas le probleme d'indispo et même s'il ne gene que quelques insomniaques, ça peut avoir des consequences sur le crawl des robots.
Je verrai ce soir pour le passage en mpm worker, de toute façon ça ne pourra pas lui faire du mal s'il peut exploiter toutes les ressources du proc. Au pire je continuerai de chercher et je vous dirai ou j'en suis.

[_Mac_]

Tu peux tenter d'utiliser nice pour réduire la priorité du cron, on ne sait jamais.

[matdam]

Je reviens avec une solution plus viable.

Le cron qui nettoie les sessions sous Debian/Ubuntu est utilisé parce que les droits du repertoire /var/lib/php5 sont trop stricte pour que le garbage collector de php puisse opérer.

Allons faire un tour dans le php.ini et penchons nous sur la directive "save_path" qui défini le chemin où sont stockés les fichiers de session. Il suffit donc de créer MANUELLEMENT un repertoire personnalisé dans notre arborescence avec tous les droits. (modifier simplement la valeur de save_path ne créera pas le repertoire automatiquement)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
session.save_path = /mon/repertoire/personnalisé/crée/manuellement/en/chmod/0777

puis identifier la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
;session.gc_probability = 0

et la changer en

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
session.gc_probability = 1

pour activer le garbage collector et finalement relancer apache.

le chmod 0777 peut ne pas etre du gout de tout le monde, mais étant donné la nature du repertoire et la durée de vie des fichiers qu'il contient, ça ne me pose pas de problème.

Merci pour votre aide.

[matdam]

Autre remarque qui pourra interesser les admin debian/ubuntu

Le week end et en heure de pointe, on ressentait d'important ralentissements au niveau du chargement des pages et des images. Depuis la modification présentée précédemment, les performances s'en sont retrouvées boostées, en heure de pointe on a l'impression d'être tout seul sur le serveur.

C'est un effet secondaire tout à fait profitable donc je conseille à tout ceux qui ont un site à fort trafic sur du Debian/Ubuntu d'effectuer cette modification (je pense qu'on peut en ressentir les effets à partir de 150k visites par jour, en tout cas à 300k c'est flagrant).