L'appel de sync/fsync ralentit l'IO après 30 minutes de fonctionnement

Après 30 minutes de fonctionnement, j'utilise Ubuntu 14.04 avec un disque dur ext4. SSD hybride Je vois de nombreux processus qui bloquent les entrées-sorties en utilisant iotop.

La cause profonde de ce ralentissement a été retracée jusqu'à l'appel système Unix sync .

Running sync à partir du terminal de façon répétée peut prendre de l'ordre de 1 à 2 secondes mais UNIQUEMENT après 30 minutes de fonctionnement.

Pour le prouver, j'ai créé un script qui affiche le temps de fonctionnement en secondes par rapport au temps d'exécution de la synchronisation, et je l'ai exécuté toutes les secondes :

while true;
do
cat /proc/uptime | awk '{printf "%f ",$1}'; /usr/bin/time -f '%e' sync;
sleep 1;
done;

J'ai exécuté le script ci-dessus, j'ai attendu environ une heure (le système est resté inactif) et j'ai tracé les résultats dans gnuplot (y = temps en secondes pour exécuter la synchronisation, x = temps de fonctionnement en secondes) :

Le moment où le graphique monte en flèche se situe vers 1780 (1780/60 = environ 30 minutes).

Rien ne devrait écrire sur le disque à ce moment-là à part le script, donc il devrait y avoir presque rien dans le cache de la page après la première synchronisation ; chaque synchronisation suivante écrira exactement ce qui est écrit dans le script, ce qui sera environ 100 octets.

Quand je vérifie cat /proc/meminfo la ligne sale (données dans le cache de la page qui doivent être sauvegardées sur le disque ?) et la ligne d'écriture (tampon du disque dur ?) sont toutes à zéro. Je pensais qu'appeler sync efface ces caches de disque mais il se bloque toujours même s'il n'y a rien dans ces caches, alors fait-il autre chose ?

Ce problème persiste après les redémarrages ; par exemple - si j'attends 30 minutes pour le ralentissement puis que je redémarre, le ralentissement sera toujours là. Si j'éteins puis redémarre, le problème disparaît jusqu'à 30 minutes plus tard.

Une autre curiosité est que lorsque j'ai examiné le graphique ci-dessus et que j'ai zoomé sur une zone où le ralentissement se produit, j'ai obtenu ceci :

Les pics et les creux se répètent - cela se produit à des intervalles de 10 secondes d'un creux à l'autre.

J'ai également effectué des tests hdparm ( hdparm -t /dev/sda y hdparm -T /dev/sda ) avant le ralentissement :

/dev/sda:
Timing cached reads:   23778 MB in  2.00 seconds = 11900.64 MB/sec
/dev/sda:
Timing buffered disk reads: 318 MB in  3.01 seconds = 105.63 MB/sec

et pendant le ralentissement :

/dev/sda:
 Timing cached reads:     2 MB in  2.24 seconds = 915.50 kB/sec
/dev/sda:
Timing buffered disk reads: 300 MB in  3.01 seconds =  99.54 MB/sec

En montrant que les lectures réelles du disque ne sont pas affectées mais que les lectures en cache le sont, cela pourrait signifier que le problème est lié au bus système et non au disque dur après tout ?

Voici les solutions que j'ai essayées :

• Modifiez les paramètres d'affichage du disque dur (le disque dur est peut-être passé en mode d'économie d'énergie) :

  hdparm /dev/sda -S252 #(set it to 5 hours before spindown)

• Changer le type de journalisation du système de fichiers en writeback plutôt qu'en ordered afin d'améliorer les performances - cela ne résout pas le problème car cela n'explique pas les 30 minutes de temps de fonctionnement sans ralentissement - quand j'ai essayé cela, il n'y avait aucun changement.

• J'ai désactivé le CRON car il semble se produire après une trentaine de minutes.

• L'utilisation du CPU est bonne et est complètement inactive, donc aucun processus ne peut être blâmé. Cependant, j'ai essayé d'arrêter tous les services, y compris le gestionnaire de session (lightdm), mais cela ne donne rien car je pense que le problème est de niveau inférieur.

• L'analyse de tout nouveau processus arrivant à 30 minutes n'indique aucun changement - j'ai comparé la sortie de PS avant et après et il n'y a aucune différence.

Cela a commencé à se produire il y a environ 2 semaines, rien n'a été installé et aucune mise à jour n'a été effectuée à cette époque. Je pense que ce problème est d'un niveau beaucoup plus bas et j'apprécierais vraiment un peu d'aide ici car je suis désemparé, même en m'indiquant la bonne direction serait utile.

La mise en cache en écriture est activée sur le disque en question, j'ai également essayé de désactiver les barrières d'écriture. Les données SMART sur le disque dur n'indiquent aucun problème avec le disque dur lui-même, mais je soupçonne le disque dur de faire quelque chose de mystérieux car le problème persiste après les redémarrages.