Go, les conteneurs et le planificateur Linux

• Applications Go dans des conteneurs : les développeurs Go déploient souvent leurs applications dans des conteneurs nécessitant des limites CPU afin d’éviter la monopolisation des ressources de l’hôte.
• Runtime Go et limites CPU : le runtime Go n’est pas intrinsèquement conscient des limites CPU d’un conteneur, ce qui peut entraîner une surutilisation et des problèmes de performances.
• Ramasse-miettes (GC) de Go : le GC de Go s’exécute de manière concurrente, mais de courtes pauses « stop-the-world » sont nécessaires à la fin du balayage et du marquage pour garantir l’intégrité des données.
• Planificateur Linux - CFS : le Completely Fair Scheduler (CFS) de Linux alloue le temps CPU de manière proportionnelle, et les processus reçoivent un temps CPU correspondant aux cœurs qui leur sont autorisés.
• Problème entre Go et CFS : Go crée un thread OS par cœur CPU, mais en ignorant les limites CPU du conteneur, il peut allonger les temps de GC « stop-the-world ».
• Configuration de GOMAXPROCS : l’utilisation de la variable d’environnement GOMAXPROCS permet d’aligner les threads OS de Go sur les limites CPU du conteneur et de réduire la latence du GC.
• Automatisation de GOMAXPROCS : la bibliothèque automaxprocs d’Uber peut configurer automatiquement GOMAXPROCS en fonction des limites du conteneur, ce qui simplifie la configuration.
• Améliorations futures du runtime Go : une issue GitHub ouverte vise à intégrer la détection automatique des limites CPU dans le runtime Go.

Conclusion : pour utiliser efficacement les ressources et maintenir de bonnes performances des applications Go dans des conteneurs, il est important de configurer correctement les limites CPU et GOMAXPROCS.

[GN⁺]

Avis sur Hacker News

• Discussion sur l’utilisation de réservations CPU plutôt que de limites CPU en environnement conteneurisé
• Problème de mauvaise détection du nombre de cœurs par les applications dans les conteneurs
• Explication détaillée des paramètres Docker CFS cgroup et recommandation d’utiliser --cpu-shares
• Retour d’expérience sur les problèmes du planificateur CFS dans les conteneurs et curiosité vis-à-vis du nouveau planificateur
• Mention de l’introduction de GOMEMLIMIT dans Go et d’un outil de configuration automatique de la limite mémoire (automemlimit)
• Partage des difficultés de gestion des limites CPU pour des déploiements Go dans un cluster Kubernetes
• Remerciements pour la mention du projet par le mainteneur de l’outil ko
• Question sur la capacité du runtime Go à reconnaître les limites des cgroups et sur l’existence de comportements similaires dans d’autres runtimes
• Discussion sur la réduction de la latence du GC en effectuant du travail concurrent avant d’atteindre un point sûr
• Mention des ajustements effectués par l’équipe .NET CLR pour des scénarios similaires en environnement conteneurisé