Bonjour,
j'ai un problème de pics de charge sur un de mes serveurs. Ces pics surviennent plus ou moins aléatoirement, et font souvent des pointes à 80-100, mais ne durent jamais plus de 2-3 secondes. Une fois passé, la charge redescend, jusqu'à que la même chose se reproduise.
- Après un peu de monitoring j'en ai déduit que le process "flush" (anciennement pdflush je pense) monopolise les disques et me fout le bordel, vu que ça me bloque un paquet de process apache pendant un certain temps. Je vois ça via top, qui m'indique que flush prend 100% de CPU, et je vois aussi les process Apache en état "D" via ps. En surveillant /proc/meminfo, je vois aussi que chaque fois que la valeur "Dirty" baisse j'ai immédiatement un process Apache bloqué.
- Aditionnellement, j'ai une ligne du genre dans iostat:
cciss/c0d0 0,01 24,03 0,05 10,48 3,12 276,16 26,51 0,01 0,58 0,35 0,37 - La 3ème colonne en partant de la fin indique la colonne await, soit le temps d'attente en queue pour insertion sur ce disque si j'ai bien compris. Hors ici c'est vraiment très peu ce temps d'attente, donc je ne comprends pas comment cela peut me bloquer.
- Je précise que nous n'écrivons quasiment rien sur ce volume (les logs d'erreur Apache, quelques traces dans un script PHP, pas écrites tout le temps). Malgré cela dstat m'indique des taux d'écriture variant entre 80Ko et 13Mo...
PS: Désolé pour la mise en page foireuse mais je vois pas comment mettre un saut de ligne, les deux espaces en fin ne marchent que pour aller à la ligne...
# Suite
Posté par Sphax . Évalué à 1.
Évidemment 2 minutes après avoir posté je me suis aperçu que sur Debian pour je ne sais quelle raison il y a un log d'accès par défaut "other_vhosts_access.log". Je l'ai désactivé, je n'ai plus ces pics pour le moment. Je verrai encore ce soir, quand j'ai le plus de trafic, si cela se reproduit.
# /proc/sys/vm/block_dump et iotop
Posté par Bruno Muller . Évalué à 1.
Tout est très bien expliqué ici par exemple : http://stackoverflow.com/questions/249570
[^] # Re: /proc/sys/vm/block_dump et iotop
Posté par Sphax . Évalué à 1.
Alors la situation est mieux qu'avant (depuis que j'ai désactivé le log caché) mais ce n'est toujours pas bon.
Avec iotop je vois que l'activité vient des process Apache. D'un coup ils se mettent à écrire environ 20Ko/s chacun. Pendant que ça se passe, avec dstat je vois le taux d'écriture grimper à 1500Ko/s, alors qu'autrement il est bas (entre 0 et 50Ko de temps en temps). Cette valeur de 1500Ko/s est aussi reporté dans iotop.
Ce qui me paraît étrange c'est qu'en surveillant la taille du volume avec df, j'ai vu une différence d'à peine une soixantaine de Ko, pas de plusieurs Mo...
# Suite
Posté par Sphax . Évalué à 1.
Alors, j'ai du nouveau.
J'ai remarqué que les écritures sur disque intervenait toutes les 30s. J'ai pensé aux intervalles que l'on peut tuner dans le noyau (vm.dirty_expire_centisecs et vm.dirty_writeback_centisecs), et bingo, dirty_expire_centisecs est par défaut à 300 100ème de seconde, soit 30s.
En pensant réduire le volume de données écrites, et écrire plus souvent mais moins longtemps, j'ai baissé ce paramètre à 10s. A mon étonnemment, les valeurs écrites n'ont pas changé, ou peu. De l'ordre de 5Mo. Ensuite j'ai augmenté la valeur à 60s, juste pour voir. Et ben pareil, j'ai les mêmes taux d'écriture sauf que maintenant cela se passe chaque minute.
En regardant le source de dstat j'ai vu qu'il se base sur /proc/diskstats pour donner ces valeurs. Est-ce que ces valeurs tiennent compte aussi des écritures des métadonnées ? Parce que je vois que ça à priori, on n'écrit pas autant de données à la minute. D'ailleurs, un "watch df" le confirme, la partition n'augmente presque pas de taille.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.