- En général, on évalue la limite de performance d’un serveur à partir du % d’utilisation CPU affiché par des outils de supervision comme
top, mais en réalité cet indicateur ne reflète pas linéairement les performances
- Des tests réalisés avec stress-ng sur un système équipé d’un Ryzen 9 5900X montrent qu’à 50 % d’utilisation, la charge de travail réelle atteint déjà 60 à 100 %, ce qui révèle un fort décalage avec l’indicateur
- Les principales causes sont l’hyperthreading et le turbo boost, car le partage des ressources entre cœurs logiques et les variations de fréquence faussent la métrique
- Il est donc plus pertinent de comparer un benchmark de la charge de travail réellement traitable au débit actuel traité, plutôt que de se fier à la seule utilisation CPU
- Interpréter l’utilisation CPU de façon linéaire entraîne de grosses erreurs d’estimation des performances ; pour la planification des systèmes, une approche fondée sur des benchmarks est nécessaire
Écart entre le taux d’utilisation CPU d’un serveur et son débit réel
- Lorsqu’on exploite un serveur, beaucoup veulent savoir s’il approche de son taux d’utilisation maximal
- En général, on se réfère à la valeur la plus élevée parmi l’utilisation réseau, mémoire et CPU via des outils de supervision comme
top
- Mais en pratique, le chiffre d’utilisation CPU et la quantité de travail réellement traitable n’augmentent pas de manière linéaire
Environnement et méthode de test
- Expérience menée sur un PC Ubuntu Desktop avec Ryzen 9 5900X (12 cœurs / 24 threads)
- Precision Boost Overdrive (Turbo) activé
- Simulation de diverses charges avec stress-ng (1 à 24 workers, 1 à 100 % d’utilisation)
- Mesures observées : utilisation CPU rapportée par le système et volume réel de calcul (Bogo ops)
Résumé des résultats
- Charge CPU générale : à 50 % d’utilisation, débit réel de 60 à 65 %
- Opérations entières 64 bits : à 50 % d’utilisation, débit réel de 65 à 85 %
- Calcul matriciel (Matrix math) : à 50 % d’utilisation, débit réel de 80 à 100 %
- En réalité, même lorsque des workers supplémentaires n’apportent aucun gain de performance, l’utilisation CPU continue d’augmenter
Analyse des causes
-
Hyperthreading
- Architecture composée de 12 cœurs physiques + 12 cœurs logiques
- Jusqu’à 12 workers, le placement sur les cœurs physiques est optimal, mais au-delà, le partage des cœurs logiques dégrade les performances
- En particulier pour les opérations SIMD (calcul matriciel), les ressources partagées ne permettent aucun gain de performance
-
Turbo boost
- À faible charge, 4,9 GHz → en pleine charge, 4,3 GHz, soit une baisse de fréquence de 15 %
- Cela fausse la formule de calcul de l’utilisation CPU (= busy cycles / total cycles)
- Comme le dénominateur (nombre total de cycles) diminue, la hausse de l’utilisation est surestimée par rapport à la charge de travail réelle
Enseignements
- L’utilisation CPU n’est pas un indicateur absolu de performance
- Pour estimer la capacité d’un serveur et prévoir ses performances :
- 1. Mesurer le débit maximal au moyen de benchmarks
- 2. Surveiller le débit en temps réel
- 3. Comparer les deux pour déterminer si l’on approche de la limite de performance
- Selon l’architecture CPU (AMD vs Intel), l’efficacité de l’hyperthreading et le mode de fonctionnement du turbo, les écarts peuvent être importants, d’où la nécessité d’une analyse par processeur
Conclusion
- L’utilisation CPU n’est rien d’autre que le rapport de cycles occupés, et ne reflète pas fidèlement les performances de traitement réelles
- Avec une utilisation efficace, 50 % d’utilisation peuvent déjà correspondre à 80 à 100 % des performances maximales
- En conséquence, la supervision des performances et la planification système doivent se concentrer sur le débit réel des charges de travail, fondé sur des benchmarks, plutôt que sur la seule utilisation CPU
Aucun commentaire pour le moment.