Traqueur, CPU

Téléchargement du traqueur pour PostgreSQL 9.4, 9.5, 9.6, 10, 11 et 12
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

      Dans l’article d’introduction sur le traqueur, j’indique qu’avoir un serveur faiblement chargé au niveau CPU (processeur) n’est pas nécessairement un bon signe pour les performances générales. Une faible charge CPU globale ne signifie même pas qu’un serveur a des performances satisfaisantes à ce niveau.
      Imaginez, si c’était possible, que vous puissiez monter en 2017 un serveur avec 1000 coeurs de la puissance d'un AMD ® 386DX @ 40 Mhz, un CPU sorti en 1991 considéré à l’époque comme une référence. Tout ne peut pas être parallélisé et, de toute façon, chaque coeur serait individuellement si lent que les performances seraient exécrables avec une charge prévue pour un serveur des années 2010. Avec un nombre restreint d’utilisateurs, cette machine aurait pourtant en permanence un taux de CPU "idle" assez impressionnant.
      Bien sûr, cette situation est caricaturale. Mais il est malgré tout intéressant de savoir si la performance d’exécution sur un thread est acceptable et correspond à la puissance théorique.
      Le traqueur dispose pour cela de tests basiques accessible via option -a. Avec l'argument 1, un grand nombre premier est calculé. Avec les arguments 2 et 3, des décimales de pi. Ces tests sont basés sur du code C de Fabrice Bellard. Le score obtenu est toujours une durée, il doit donc être le plus faible possible. Démonstration :

./traqueur.sh -a 2 traqueur 3.01.01 - outil de diagnostic performance pour PostgreSQL 9.4 => 12 INFORMATION, test CPU ... INFORMATION, score CPU (s) ... 137

Quelques résultats obtenus

VirtualisationOSType de coeurTest 1, temps en sTest 2, temps en sTest 3, temps en s
N/AUbuntu 16.04 LTSIBM ® PowerPC_POWER9 @ 2.30 GHz75431405
N/AUbuntu 18.04 LTSIntel ® Core CPU I7- 7700HQ @ 2.80 GHz104137186
LPARAIX 6.1 TL9 SP7IBM ® PowerPC_POWER8 @ 3.40 GHz147534493
VmwareRHEL 7.4Intel ® Xeon® CPU E5-2650 v3 @ 2.30 GHz162
KVM Debian 9.5Intel ® Core Processor (Haswell, no TSX) -- CPU VPS 2016 ovh179192281
VirtualboxDebian 9.0Intel ® Core CPU I7-4710HQ @ 2.50 GHz180
VmwareRHEL 7.2Intel ® Xeon® CPU X5670 @ 2.93 GHz184
VmwareRHEL 7.4Intel ® Xeon® CPU E5-4640 @ 2.40 GHz204209303
VmwareDebian 8.7Intel ® Xeon® CPU E7-4860 @ 2.27 GHz205
VmwareDebian 8.6Intel ® Xeon® CPU E5-4627 v4 @ 2.60 GHz207233339
VmwareDebian 8.7Intel ® Xeon® CPU E7-4850 @ 2.00 GHz239232336
LPARAIX 7.1 TL4 SP2IBM ® PowerPC_POWER7+ @ 3.70 GHz264
Xen Debian 9.5Intel ® Xeon ® CPU E5-2603 v2 @ 1.80 GHz265277397
VirtualboxUbuntu 16.04 LTSAMD ™ Phenom II X6 1090T @ 3.20 GHz303139237
LPARAIX 7.1 TL4 SP2IBM ® PowerPC_POWER7 @ 3.00 GHz349
N/AAndroid 6.0.1Qualcomm ® MSM8939 Snapdragon 615 @ 1.5 GHz383400494
N/AAIX 6.1 TL8 SP2IBM ® PowerPC_POWER6 @ 4.70 GHz388559642
Hyper-VRHEL 7.2Intel ® Xeon® CPU E5-2640 @ 2.50 GHz395
N/AAIX 6.1 TL9 SP4IBM ® PowerPC_POWER6 @ 4.20 GHz432632721
LPARAIX 6.1 TL8 SP2IBM ® PowerPC_POWER7 @ 2.46 GHz517

      Les résultats obtenus n'ont pas grande valeur dans l'absolu. Ils doivent être utilisés pour évaluer le même CPU à différentes périodes.
      Le serveur soupçonné de lenteur et présentant effectivement une anomalie au regard de sa configuration est ici la machine virtuelle Hyper-V/RHEL 7.2. Ses coeurs Xeon E5-2640 devraient lui donner un score autour des 200s au 1er test alors qu’elle obtient en fait 395s. L’information a été remontée à l’équipe concernée et une intervention a été réalisée. Je ne connais pas les détails mais il semble qu’un simple reboot de l’hôte et donc des machines virtuelles ait permis de retrouver un score conforme à la puissance théorique ainsi que des performances ressenties acceptables pour les utilisateurs.
      Autre particularité : le serveur obtenant une note de 517 au 1er test ne disposait que d'une fraction de la puissance d'un coeur, ce qui explique sa note.

Conclusion

      Comme avec la latence I/O, il n’y a pas de "bonne" valeur dans l’absolu. La "bonne" valeur pour chaque élément est celle qui permet à cet élément de ne pas être un goulet d’étranglement et d’obtenir des performances globalement acceptables. Inutile de rajouter du CPU alors que le problème est au niveau des I/O etc.

Mise à jour : 03/10/2018