Traqueur, latence I/O

Un facteur majeur

Téléchargement du traqueur pour PostgreSQL 9.6 et 10
Journal des changements
Signalement de bugs via le forum
Licence identique à celle de PostgreSQL, open source type BSD
Dossier des versions

      Plus que le débit, la latence I/O constitue généralement un facteur majeur dans la performance SGBD.
      Le traqueur inclut une option -l permettant d’effectuer un relevé basique de la latence I/O (avec accès aléatoires) basé sur Bonnie++.
      Bonnie++ a des capacités trés étendues et vous permettra d’affiner les résultats si nécessaire.
      Comme le test CPU/RAM (option -a), ce test doit impérativement être exécuté depuis le serveur de base de données alors que le reste des diagnostics peut être effectué à distance grâce à l’option -c.

      Premier relevé :

postgres@srvdeb96:~$ ./traqueur.sh -l traqueur 0.08.02beta - outil de diagnostic performance pour PostgreSQL 9.6, 10 AVERTISSEMENT, commande bonnie++ inaccessible, ajout de /usr/sbin au PATH INFORMATION, test latence avec bonnie++ ... Latence I/O : 311ms ... Latence I/O : 205ms ... Latence I/O : 198ms

      srvdeb96 est une machine virtuelle Virtualbox stockée sur un unique disque dur classique 5400rpm. La latence obtenue est de 300ms lors de la 1ere exécution, autour de 200ms lors des suivantes. La latence I/O de ce système est comme prévu très mauvaise. Sauf cas très particulier, à moins par exemple de travailler quasi exclusivement en RAM, les performances seraient donc catastrophiques si un tel système était utilisé en production.

      Deuxième relevé :

postgres@vps197701:~$ ./traqueur.sh -l traqueur 0.08.02beta - outil de diagnostic performance pour PostgreSQL 9.6, 10 AVERTISSEMENT, commande bonnie++ inaccessible, ajout de /usr/sbin au PATH INFORMATION, test latence avec bonnie++ ... Latence I/O : 6218us ... Latence I/O : 5600us ... Latence I/O : 7031us

      vps197701 est une machine virtuelle KVM, le stockage est basé sur du RAID SSD. La latence obtenue est comprise entre 5 et 7ms. Elle est logiquement bien meilleure que celle obtenue précédemment. Bien sûr, dans les années 2010, il vaut toujours mieux malgré tout travailler autant que possible en mémoire vive qui reste bien plus rapide qu’un stockage SSD.

      Troisième relevé :

postgres@sv-t-vtl-bas10:~$ ./traqueur.sh -l traqueur 0.09.00beta - outil de diagnostic performance pour PostgreSQL 9.6, 10 AVERTISSEMENT, commande bonnie++ inaccessible, ajout de /usr/sbin au PATH INFORMATION, test latence avec bonnie++ ... Latence I/O : 19496us ... Latence I/O : 15443us ... Latence I/O : 15044us postgres@sv-t-vtl-bas10:~$ ./traqueur.sh -l traqueur 0.09.00beta - outil de diagnostic performance pour PostgreSQL 9.6, 10 AVERTISSEMENT, commande bonnie++ inaccessible, ajout de /usr/sbin au PATH INFORMATION, test latence avec bonnie++ ... Latence I/O : 5268us ... Latence I/O : 4637us ... Latence I/O : 4247us

      sv-t-vtl-bas10 est une machine virtuelle XEN, le stockage est basé sur du SAN d’entrée de gamme. La latence obtenue est comprise entre 15 et 20ms alors que le SAN est chargé, 4 à 5ms dans une période plus calme.

Conclusion

      Quelle est la "bonne" valeur ? Celle qui vous permet d’obtenir des performances acceptables bien sûr !
      Les chiffres obtenus ici constituent juste une indication. Je vous conseille de procéder à des mesures sur vos systèmes, sans attendre que la situation soit dégradée, afin de pouvoir procéder par comparaison. Notez la latence obtenue quand tout va bien et conservez cette mesure. Effectuez un test lorsque les performances se dégradent, notamment si un rapport ou une exécution classique du traqueur vous incitent à considérer un problème I/O (par exemple si le profil de charge montre un pourcentage de wait_event_type = IO en hausse par rapport à la normale).

Mise à jour : 10/07/2017