Téléchargement du traqueur pour PostgreSQL 12, 13, 14, 15, 16
Téléchargement du traqueur pour PostgreSQL 11
Téléchargement du traqueur pour PostgreSQL 10
Téléchargement du traqueur pour PostgreSQL 9.6
Téléchargement du traqueur pour PostgreSQL 9.5
Téléchargement du traqueur pour PostgreSQL 9.4
Téléchargement du traqueur pour PostgreSQL 9.3
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é :
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é :
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é :
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).