Les appels à sync / fsync ralentissent après 30 minutes de disponibilité

Après 30 minutes de disponibilité en utilisant Ubuntu 14.04 avec un SSD hybride, je vois de nombreux process bloquant les iotop sorties en utilisant iotop . C'est lors de l'écriture sur le disque, par exemple si j'ouvre et ferme un file vide dans gedit, cela peut prendre 2 secondes pour fermer en raison des parameters d'écriture dconf, cela affecte d'autres applications d'une manière similaire; ralentissant considérablement le système entier.

En utilisant strace j'ai réussi à retracer cela à un appel fsync et à partir de là réussi à le reproduire en utilisant la command de synchronisation.

Donc, pour récapituler, il suffit de lancer la sync partir du terminal à plusieurs resockets peut prendre de l'ordre de 1 à 2 secondes, mais seulement après 30 minutes de disponibilité.

Pour le prouver, j'ai créé un script qui affiche le time de réponse en secondes par rapport au time nécessaire à l'exécution de la synchronisation et l'exécute 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, attendu environ une heure (le système était resté inactif), puis j'ai tracé les résultats dans gnuplot (y = time en secondes pour exécuter la synchronisation, x = time de disponibilité en secondes)

Temps de synchronisation en fonction de la disponibilité

Le point dans le time où les pointes de graphique est autour de 1780 (1780/60 = environ 30 minutes).

Rien ne devrait écrire sur le disque en dehors du script, donc il ne 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 qui sera d'environ 100 octets ou alors.

Ce problème persiste après les redémarrages; par exemple – si j'attends 30 minutes pour le ralentissement puis redémarre, le ralentissement sera toujours là. Si je détwig 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 zoomé sur une zone où le ralentissement se produit, j'ai eu ceci:

temps de synchronisation en fonction de la disponibilité, zoom avant

Les pics et les creux se répètent – cela se produit presque exactement toutes les 10 secondes du creux au creux et aussi le pic se plie quand il descend.

J'ai également exécuté des tests hdparm ( hdparm -t /dev/sda et 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 

Montrer que les lectures réelles du disque ne sont pas effectuées, mais les mises en cache sont, cela pourrait-il signifier que cela est à faire avec le bus système et non pas la HD après tout?

Voici les solutions que j'ai essayées:

  • Changer les parameters de spindown de la HD peut-être la HD passait en mode d'économie d'énergie:

     hdparm /dev/sda -S252 #(set it to 5 hours before spindown) 
  • Changez le type de journalisation du système de files en écriture différée plutôt qu'en ordre afin d'get des améliorations de performance – cela ne résout pas le problème car cela n'explique pas le time de fonctionnement sans ralentissement de 30 minutes.

  • CRON désactivé comme il semble se produire après un tour de 30 minutes.

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

  • L'parsing de tous les nouveaux process à 30 minutes n'indique aucun changement. J'ai différé la sortie de PS avant et après et il n'y a pas de différence.

Cela n'a commencé qu'à se produire il y a environ 2 semaines, rien n'a été installé et aucune mise à jour n'a été effectuée à ce moment-là. Je pense que cette question est beaucoup plus faible donc j'apprécierais vraiment une aide ici car je n'ai aucune idée, même me diriger dans la bonne direction serait utile – par exemple existe-t-il un moyen d'examiner ce qui est débusqué sur le cache de la page?

La caching d'é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 la HD n'indiquent aucun problème avec la HD elle-même mais j'ai mes soupçons que c'est la HD qui fait quelque chose de mystérieux car elle persiste après les redémarrages.

MODIFIER:

J'ai fait:

 watch -n 1 cat /proc/meminfo 

… pour voir comment la memory change en regardant particulièrement la rangée sale et la ligne de réécriture qui, je crois, est la memory tampon du disque HD. Ils restnt tous à zéro, la plupart étant probablement 300kb. L'appel de la synchronisation renvoie ceux-ci comme prévu à 0 mais pendant le ralentissement appelant la synchronisation quand il n'y a pas de pages sales et que zéro kb dans le tampon du disque verrouille encore IO. Que pourrait faire d'autre la synchronisation s'il n'y a rien pour débusquer le cache de la page et écrire le cache?

Les symptômes sont très cohérents avec un système d'E / S principalement saturé, mais la plupart du time, les charges d'E / S du côté de l'espace user / user sont exclues, ce qui peut inclure la lecture de tous les secteurs. Cela devrait être interrogeable / réglable de smartctl (Au less un endroit étant smartctl-c pour l'interrogation).

En ce qui concerne pourquoi il va et vient et a commencé soudainement maintenant:

  • Le lecteur a passé une certaine étape dans sa vie (nombre de secteurs écrits, time écoulé, etc.) et le firmware sur le lecteur a déclenché l'un de ces scans
  • Je crois que cela peut également être déclenché via smartctl, donc il est possible que certains process automatisés l'ont déclenché
  • Si l'un de ces scans est déclenché et signalé comme étant en cours ou démarré, lorsque le lecteur a passé un certain time sous tension, il est déclenché de nouveau ou recommence là où il s'est arrêté