Serveur Ubuntu : /var full ce dimanche

Vous l'avez probablement constaté : CULButte.be a été indisponible un moment cet après-midi.

Le problème est un "bête" manque d'espace dans une partition !

J'avais créé des partitions qui me semblaient correctes. Mais les nombreuses mises à jour sur le site avec les photos de l'Install Party à Anderlues ce samedi, ont posé un problème. Bizarrement, ce n'est pas le dossier contenant la base de données MySQL qui était en cause ! C'était la partition /var qui était pleine.

Sur ce graphique Munin, on voit bien l'augmentation conséquente de l'occupation de la partition /var

Cela a augmenté légèrement samedi en soirée quand j'ai mis les premières photos, et très fortement après 1h du matin quand j'ai massivement importé les 117 photos de la galerie Anderlues. Et j'ai insisté, puisque j'ai recommencé 2 ou 3 fois pour corriger certains détails de rotations d'image en mode portrait, etc.

La chute après le reboot correspond au nettoyage du dossier /var/log en supprimant quelques fichiers, et surtout en déplaçant ce dossier /var/log/ dans une partition /dev/sda8 séparée. On voit cette nouvelle partition /var/log sous la forme d'une ligne rose.

Le responsable, c'est le log de MySQL dans /var/log/mysql, qui avait atteint 2 GB, alors que ma partition /var ne faisait que 4,4 GB, en comptant le reste, tout était occupé. J'aurais pu simplement supprimer une partie des fichiers de log, vu que ce n'est que du log et que de toute façon logrotate les fait tourner tous les jours. Mais cela n'aurait pas empéché le problème de se reproduire lors d'un prochain ajout massif de photos

La tâche MySQL elle-même ne semble pas avoir eu trop de problème quand on ne regarde que débits et transactions.

Il y a une pointe vers 1h du matin et une cet après-midi.

Mais si on regarde le nombre d'occurances de MySQL, ça monte en flèche lors du blocage dû au manque de place disque :

Et le serveur Web Apache... là, il est plutôt mal en point aussi !

On voit clairement qu'Apache est bloqué et que toutes les requètes Web s'accumulent. Apache lance des tâches supplémentaires pour essayer d'absorber cet afflux de requètes, mais n'arrive pas à résoudre le problème évidemment, puisque chaque nouvelle tâche est à son tour bloquée en n'arrivant pas à écrire ses logs sur disque ! On passe ainsi de 10 tâches Apache en attente à plus de 100 occurences occupées avec toujours 10 Apaches en réserve.

Le nombre de process total dans le système monte également :

On voit la chute et la remontée progressive vers un état stationnaire et normal après le reboot du serveur.

Le cpu lui-même a très bien tenu le choc :

Il y a une montée vers 1h du matin, mais pas une saturation, quand j'ai fait intensivement des imports de photos, ce qui implique aussi des redimensionnements des photos pour générer les vignettes. Par contre cela se calme lors du problème d'espace disque : les tâches sont bloquées mais ne consomment pas de cpu à ce moment là.

La ligne verticale blanche correspond à un arret de Munin pendant la reconfiguration et le reboot du serveur.
La ligne verticale rose correspond à un backup (rsync dans un ssh) d'un serveur chez OVH : à ce moment là il y a beaucoup de compression et décompression, mais aussi des I/O waits (en rose) car la tâches BackupPC attend les données envoyées depuis le serveur OVH.

Au niveau mémoire, on a eu un peu de pagination en swap pendant le problème. C'est dû aux nombreuses tâches Apache et MySQL lancées à ce moment là :

L'augmentation de l'occupation mémoire par les applications en vert ce n'est finalement pas préoccupante car ce n'est visiblement pas la mémoire de 1 GB qui limite.

Pour info, voici ce que donnait le graphique d'occupation mémoire il y a 2 mois avant le changement de serveur. A ce moment la mémoire Ram était de 384 MB :

Le graphique était beaucoup plus perturbé, preuve qu'on dépassait régulièrement la mémoire physique de 384 MB en paginant sur disque :

Les pointes de pagination de fin décembre 2008 à début février 2009 montraient qu'on arrivait à ce moment à saturer le serveur. Il paginait et devenait très lent. C'est cela qui m'a décidé à changer de carte mère, pas tellement pour l'augmentation de vitesse de 833 MHz à 1,2 GHz, mais surtout pour l'augmentation de mémoire en passant de 384 MB de SDram à 1 GB de DDR2 !

Et ce changement a été efficace !

ps :les statistiques sur un serveur, ça sert ! Aussi bien en cas de problème ou d'attaque pour cerner l'origine de ce qui bloque, que pour suivre l'évolution de la charge, de l'occupation disque, etc