Traqueur, CPU

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

      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 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 depuis la version 0.9.00 d’un test basique accessible via option -a. Il consiste à compiler et exécuter un code C de Fabrice Bellard calculant le plus grand nombre premier connu en 2017. Le score obtenue est une durée, il doit donc être le plus faible possible. Démonstration :

postgres@srvdeb10:~$ ./traqueur.sh -a traqueur 0.10.00beta - outil de diagnostic performance pour PostgreSQL 9.6, 10 INFORMATION, test CPU de calcul du plus grand nombre premier connu en 2017 ... Score CPU (s) : 180

Quelques résultats obtenus

VirtualisationOSType de coeurTemps en s
N/AUbuntu 16.04 LTSIntel ® Core CPU I7- 7700HQ @ 2.80 GHz105
LPARAIX 7.1 TL4 SP2IBM ® PowerPC_POWER8 @ 3.50 GHz162
VirtualboxDebian 9.0Intel ® Core CPU I7- 4710HQ @ 2.50 GHz180
Vmware RHEL 7.2Intel ® Xeon® CPU X5670 @ 2.93 GHz 184
KVM Debian 9.0Intel ® Core Processor (Haswell, no TSX) 198
VmwareDebian 8.7Intel ® Xeon® CPU E7- 4860 @ 2.27 GHz 205
VmwareDebian 8.6Intel ® Xeon® CPU E7- 4850 @ 2.00 GHz 241
LPARAIX 7.1 TL4 SP2IBM ® PowerPC_POWER7+ @ 3.70 GHz264
Xen Debian 9.0Intel ® Xeon ® CPU E5-2603 v2 @ 1.80 GHz267
VirtualboxUbuntu 16.04 LTSAMD ™ Phenom II X6 1090T @ 3.20 GHz311
LPARAIX 7.1 TL4 SP2IBM ® PowerPC_POWER7 @ 3.00 GHz349
N/AAndroid 6.0.1Qualcomm ® MSM8939 Snapdragon 615 @ 1.5 GHz383
Hyper-VRHEL 7.2Intel ® Xeon® CPU E5-2640 @ 2.50 GHz395
LPARAIX 6.1 TL8 SP2IBM ® PowerPC_POWER7 @ 2.46 GHz517

      Pour différentes raisons (SMT, compilation non optimale etc.), les IBM Power 7/7+ et dans une moindre mesure les IBM Power 8 sont défavorisés dans ce test donc les comparaisons sont surtout valables à architecture équivalente.
      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 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.

Conclusion

      Ecore une fois, il peut être intéressant de relever le score lorsque tout va bien afin d’avoir un élément de comparaison lorsque la situation se dégrade.
      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 : 23/08/2017