Auto-hébergement : IOwait m’a tuer 1/2 (vmstat, mpstat, atop, pidstat)

« Rien à péter, je suis passé au SSD… » (Bernard M., passionné par la fuite en avant)

IOwait : le mal aimé

« IOwait correspond au temps d’attente du système pour l’écriture ou la lecture de données. Un IOwait de 10 % signifie que 10 % de l’activité du CPU n’est pas destinée à faire des calculs mais à attendre l’exécution d’une opération de lecture/écriture. » (Wikipedia)

Pour afficher le pourcentage d’IOwait, c’est « vmstat » qui s’y colle :

# vmstat 1

procs  -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff   cache   si   so    bi    bo   in   cs  us sy id wa
1  0   7680  32200 353264 3111032    0    0 17173 19114  752  536   0  3 72 25
0  1   7680  31124 353376 3114680    0    0 12722 12798  799  569   0  3 75 22
0  1   7680  32916 353396 3114088    0    0  4592  4689  940  552   0  2 76 22
0  1   7680  33208 353432 3117292    0    0 20621 20533  739  592   0  4 77 19
1  1   7680  32096 353448 3119244    0    0 18426 18563  771  592   0  4 77 20

La colonne qui nous intéresse est la dernière, celle qui se nomme « wa ». Plus cette valeur (en pourcentage) est élevée, plus le processeur se tourne les pouces parce que les disques durs sont littéralement à la bourre et n’arrivent pas à suivre la cadence.

Notez que, jusqu’ici tout va bien : « seulement » 20% d’IOwait (mais attendez un peu la suite).

IOwait le retour : petite tentative de démystification

La plupart du temps, quand on cherche rapidement des infos sur le sujet, on tombe surtout sur des personnes plus stressées les unes que les autres : « IOwait à 100%, suis-je maudis ? », « Trop d’IOwait, mon serveur rame à mort. » ou encore « J’ai un load average de fou à cause des IOwait, que faire ? ».

Ceci étant, pas de panique car pour réduire les IOwait, il suffit d’appliquer une des solutions suivantes :

  • diminuer le nombre d’accès disque (Super, t’en as d’autres comme ça ?)
  • augmenter la charge du processeur (Gné ? Keskidi ?)
  • opter pour un processeur poussif (Chérie, fais gaffe, ce type est complètement con…)

Et pourtant, je vous assure que ça marche : installez cpuburn sur un serveur saturé au niveau des IO, lancez autant de burns que le processeur a de coeurs et admirez le résultat.

Félicitations, les IOwait sont maintenant à 0%, n’hésitez pas à demander une augmentation à votre boss…
(Cependant, si le CPU crame à cause de vos conneries, ça va être une autre paire de manche)

J’en vois certains qui froncent les sourcils et c’est bien normal : le nombre d’accès disques n’a pas baissé d’un pouce (et le processeur est à bloc), alors c’est quoi l’embrouille ?

Lire la suite…


Auto-hébergement : ma ligne ADSL est morte, que faire ?

Bien fait ! Fallait y réfléchir avant…

Note à moi-même : configurer d’urgence un MX secondaire, planifier un hébergement de secours, acheter un second modem/routeur (on sait jamais…) et ne pas oublier d’ajouter le café ainsi que le sucre à la liste des courses.

Bref, mardi dernier dans la matinée, je sirotais tranquillement mon déca-cappuccino-triplement-recaféiné et paf : plus de débit, plus de ping, plus de connexion, plus rien.

Comprenez-moi bien : trois visiteurs déboulent chaque jour sur ce blog et, de ce fait, une interruption de service n’est pas envisageable. Bah vi, ce serait une perte grave pour l’humanité toute entière car Internet serait diminué.1

Gestion de crise dans la panique : comment gruger « Elle-Sait-Faire »

Dans l’immédiat, le problème n’est pas de savoir pourquoi la ligne ADSL a sautée mais de rétablir la connectivité au plus vite.

J’ai smartphone, OK. C’est un Android, OK. On peut faire du tethering, OK. SFR interdit formellement cette pratique dans ses CGV si on n’a pas souscrit cette option au prix fort, OK.

Heu… Ah non, zut ! Bon, faut voir. Non, en fait, et après avoir mûrement réfléchi 3 secondes : rien à foutre.

Lire la suite…

  1. Si vous ne voyez à qui je fais allusion, votre éducation est à refaire. ^^