Analyse de l'impact sur les performances de la source de temps sélectionnée dans le système

Brendan Gregg, l'un des développeurs de DTrace, qui développe actuellement des outils d'analyse des performances basés sur BPF dans le noyau Linux, a résumé l'expérience acquise lors de l'analyse des problèmes de performance rencontrés par Netflix lors de la migration de la base de données Cassandra de CentOS vers Ubuntu dans des environnements exécutés sur Amazon EC2 basés sur Xen. Après la migration, la charge CPU a augmenté de 30 % et les délais d'exécution des opérations d'écriture ont approximativement augmenté dans la même mesure. Il s'est avéré que les performances des applications qui interrogent intensivement des informations temporelles dépendent fortement de la source de temps précise choisie dans le système.

Au départ, la cause de la baisse de performance n'était pas évidente et le diagnostic a commencé par le suivi de l'impact possible des processus systèmes gourmands en ressources, fonctionnant en continu ou lancés périodiquement, à l'aide des utilitaires top et execsnoop. Mais tout indiquait que la consommation des ressources avait augmenté spécifiquement dans la base de données Cassandra, écrite en Java. La comparaison des indicateurs de profilage de deux processus Cassandra, exécutés parallèlement sous CentOS et Ubuntu et traitant les mêmes requêtes, a montré qu'environ 32 % de l'ensemble du temps était consacré à l'appel de os::javaTimeMillis(), utilisé pour obtenir des informations sur l'heure actuelle.

Un experimento a ensuite été réalisé, au cours duquel une simple application en Java a été écrite, appelant dans une boucle la méthode System.currentTimeMillis() cent millions de fois. Le lancement de l'application a montré qu'il fallait 13 secondes pour exécuter celle-ci sous CentOS, tandis qu'elle prenait environ 68 secondes sous Ubuntu, c'est-à-dire cinq fois plus lent. Un programme similaire a été écrit en C, appelant la fonction gettimeofday() cent millions de fois, mais des résultats analogues ont été obtenus lors de son exécution.

Il est devenu évident que la fonction de retour de l'heure actuelle était à l'origine du problème, l'attention s'est donc portée sur la modification des indicateurs lors du choix de différentes sources de temps précis dans le système. Selon le contenu de « /sys/devices/system/clocksource/clocksource0/current_clocksource », par défaut, lors du démarrage de Linux dans le système invité, le minuteur « xen » était utilisé. Après avoir changé la source de temps pour « tsc », le temps d'exécution de l'application de test sur Ubuntu a diminué de 68 à 3,3 secondes, soit une accélération par 20 fois. Un test de performance supplémentaire de la source de temps kvm-clock a montré une augmentation des latences de 20 % par rapport à TSC. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ time java TimeBench real 1m8.300s user 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench real 0m3.370s user 0m3.353s sys 0m0.026s

Pour obtenir le temps en choisissant la source TSC, l'instruction CPU RDTSC est utilisée, dont l'exécution ne nécessite pas d'appel système (l'instruction ne nécessite pas de privilèges élevés et renvoie une valeur depuis le compteur à temps embarqué dans le CPU). Par défaut, TSC n'est pas activé car, dans le passé, cette source ne prévenait pas le décalage progressif du temps, qui dans d'autres gestionnaires est corrigé par logiciel pour obtenir des mesures plus précises. Selon un ingénieur spécialisé dans le développement de processeurs, les inquiétudes concernant les décalages de temps lors de l'utilisation de TSC ne sont plus fondées et dans les processeurs modernes cette source peut fournir des mesures stables pendant des années.

La migration des opérations serveurs vers Netflix sur la source TSC a entraîné une réduction des latences d'enregistrement de 43 % et a abouti à des résultats sur Ubuntu quatre fois supérieurs à la configuration CentOS utilisant la source de temps « xen ». Les résultats de cette étude ont été transmis à Amazon, qui a officiellement recommandé d'utiliser par défaut la source de temps TSC dans les environnements AWS EC2 basés sur l'hyperviseur Xen (dans les environnements basés sur l'hyperviseur Nitro, le kvm-clock reste recommandé).

Source : opennet.ru