- Netflix a migré un microservice Java très consommateur de CPU de m5.4xl (16 vCPU) vers m5.12xl (48 vCPU)
- Comme le nombre de vCPU était multiplié par 3, l’équipe s’attendait à un gain de performance d’environ 3x, mais le débit n’a augmenté que de 25 %
- Pire encore, la latence a chuté de 50 %, et les profils CPU comme les profils de latence sont devenus très « hachés » (choppy)
- Un article qui retrace le parcours de résolution jusque dans les couches les plus bas niveau
Processus de résolution
- L’équipe a décidé de comparer le nœud rapide et le nœud lent
- Ni les Flame Graphs ni le profiling JVM (avec JFR - Java Flight Recorder) n’ont permis d’identifier une différence
- Comme rien d’anormal n’apparaissait au niveau de l’application, de l’OS ou de la JVM, ils ont examiné les PMC (Performance Monitoring Counters, compteurs PMU) fournis par l’instance m5.12xl
- L’un des problèmes était le « False Sharing » : un schéma qui apparaît lorsque deux cœurs lisent ou écrivent des variables sans lien partageant la même ligne de cache L1
- Le problème a été résolu dans le code du JDK en insérant des octets de padding qui modifient uniquement l’organisation des données, sans changer le comportement
- Un autre problème était le « True Sharing » : plusieurs threads/cœurs lisent et écrivent la même variable
- Pour le résoudre, ils ont évité d’écrire dans une variable partagée et contourné le secondary super class cache de la JVM
- Une fois les deux correctifs appliqués, la vitesse a été multipliée par 3,5 par rapport au point de départ
- En résolvant ce problème, ils ont aussi découvert le bug JDK-8180450, resté dormant pendant 5 ans
Conclusion
- On a tendance à considérer la JVM comme un environnement d’exécution hautement optimisé, capable de rivaliser avec des langages orientés performance comme le C++
- C’est vrai pour la plupart des workloads, mais pour certains cas précis, les performances peuvent dépendre non seulement de l’implémentation de l’application, mais aussi de celle de la JVM elle-même
- Dans ce cas, ils ont utilisé les PMC pour identifier et corriger un goulot d’étranglement dans le code natif de la JVM, ce qui a permis d’augmenter le débit de plus de 3x sur ce workload
- Pour ce type de problème de performance, la seule véritable solution est la capacité à observer l’exécution au niveau de la microarchitecture CPU
- Intel vTune fournit des enseignements précieux même avec les seuls PMC essentiels exposés par des instances comme m5.12xl
- Si toutes les instances cloud fournissaient un ensemble complet de PMC avec PEBS (Processor Event-Based Sampling), une analyse bien plus approfondie permettrait d’obtenir des gains de performance encore plus importants
2 commentaires
Wa, mais sérieusement...
Ça a dû être grisant quand l’hypothèse a été validée puis corrigée.