J'ai passé ce samedi (et le week-end dernier) à aider @Kysofer à monter un serveur de stockage pour son entreprise et là nous nous sommes rendus compte que tout ramait, mais genre vraiment.

Je vous retrace l'enquête ? Vous êtes chô mes lapins ? Aller c'est parti :D

D'abord et pour vous illustrer notre problème, il a fallu quelque chose comme 30 sec pour installer htop après l'avoir téléchargé depuis une connexion fibrée sur une machine quadricore, 4Go RAM / SATA-III... Bref, le sentez-vous aussi ce problème qui va être bien pourri à identifier.

Étape 1 - Vérification de l'état du CPU
Tout semble normal, htop indique une charge globale oscillant entre 2% et 5% pour 90 Mo de RAM consommée. Nous faisons également un tour dans journalctl pour nous assurer qu'il n'y ait pas quelque chose de suspicieux d'indiqué.

=> Réponse : NADA

Étape 2 - Vérification des processus s'exécutant en tâche de fond
Un petit coup de sudo service --status--all et sudo systemctrl list-units pour regarder ce qui tourne en tâche de fond et rien non plus. D'ailleurs cela corrobore le fait que le load average s'affiche aux alentours de 2,5 pour 16 processus créés, 1 running et 4 threads physiques de dispo.

Par contre, nous remarquons que l'OS swappe, alors que la consommation mémoire n'excède pas 100 Mo sur 4 000 Mo... Étonnant non ?

Étape 3 - Réduction de la swappiness
Au vu du résultat précédent, nous allons faire un petit tour dans /etc/sysctl.conf pour y ajouter la ligne vm.swappiness = 1 comme je l'explique dans ce post

Pour vous le préciser et parce que beaucoup de lectures seront faites, les RAID1 sont montés en noatime et nodiratime.

=> Bref un petit reboot et, et ? Et toujours rien...

Étape 4 - Identification de la charge du disque
Nous installons iotop afin de déterminer si un processus écrit en permanence sur le disque (car @Kysofer me disait qu'il entendait les disques crépiter). Et là, premier indice : une coquine de charge résiduelle se maintient à ~3Mo/sec en écriture. WTF oÔ ?

Un petit coup d’œil sur la grille des process et nous identifions un potentiel coupable : ext4lazyinit. Sur le coup, nous nous disons "mais c'est quoi ce truc là ?"

Explication
Lorsque vous initialisez un disque dur pour la première fois, et dans notre cas il s'agissait de 6 partitions réparties comme suit :

• Deux disques de 320 Go notés sda et sdb
• Deux disques de 10 To notés sdc et sdd

Les partitions étaient les suivantes :

• 10 Go d'attribués pour l'OS sur sda.
• 10 Go d'attribués pour la SWAP sur sdb.
• Un RAID1 de 310 Go, noté md0, monté sur l'espace restant partagé entre sda et sdb (ce sera notre /home).
• Un RAID1 de 10 To, noté md1, et monté sur les disques sdc et sdd.

Eh bien l'OS ne défini pas tous les secteurs à zéro, or il semble que ce soit une nécessité pour initialiser la table EXT4 sur les disques vierges... Ce process étant bloquant pour l'accès aux ressources disques, il se lance en priorité basse et tourne en tâche de fond. Lorsque l'initialisation sera terminée, tout sera rentré dans l'ordre... Notre problème ici est que nous avons 26,4 To à initialiser avec des zéros et le bouzin se limite à 3 Mo /sec... #Subarashi #Sugoi

Notre solution : prendre notre mal en patience...

Franchement, on dirait une manipulation à la Microsoft... Un peu comme si cette société était devenue l'une des plus grosses contributrices au noyau Linux depuis quelques temps. Oh wait...