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 en analysant les problèmes de performances rencontrés par Netflix lors de la migration du SGBD Cassandra de CentOS vers Ubuntu. le cloud Amazon EC2 basé sur Xen. Après la migration, la charge du processeur a augmenté de 30 % et les délais lors des opérations d'écriture ont augmenté à peu près dans la même mesure. Il s'avère que les performances des applications qui demandent intensivement des informations temporelles dépendent dans une large mesure de la source horaire exacte sélectionnée dans le système.

Au début, la raison de la diminution des performances n'était pas évidente et le diagnostic a commencé par la surveillance de l'impact possible de processus système constamment exécutés ou lancés périodiquement et gourmands en ressources à l'aide des utilitaires top et execsnoop. Mais tout indiquait que la consommation de ressources avait augmenté spécifiquement dans le SGBD Cassandra, écrit en Java. La comparaison des métriques de profilage de deux processus Cassandra exécutés en parallèle sur CentOS et Ubuntu, traitant les mêmes requêtes, a montré qu'environ 32 % du temps total était consacré à l'appel de os::javaTimeMillis(), qui est utilisé pour obtenir des informations sur l'heure actuelle. .

Après cela, une expérience a été menée dans laquelle une simple application Java a été écrite, appelant la méthode System.currentTimeMillis() cent millions de fois en boucle. L'exécution de l'application a montré qu'il fallait 13 secondes pour terminer sur CentOS et environ 68 secondes sur Ubuntu, c'est-à-dire 5 fois plus lent. Un programme similaire a été écrit en C et a appelé la fonction gettimeofday() cent millions de fois, mais une fois exécuté, des résultats similaires ont été obtenus.

Puisqu'il est devenu évident que la source du problème était la fonction de renvoi de l'heure actuelle, l'attention s'est portée sur les changements d'indicateurs lors du choix des différentes sources d'heure exacte dans le système. À en juger par le contenu de « /sys/devices/system/clocksource/clocksource0/current_clocksource », le minuteur « xen » était utilisé par défaut lors de l'exécution de Linux sur le système invité. Après avoir changé la source de temps en "tsc", le temps d'exécution de l'application de test dans Ubuntu est passé de 68 à 3.3 secondes, soit c'est devenu 20 fois plus rapide. De plus, un test de performances de la source temporelle kvm-clock a été effectué, qui a montré une augmentation des retards de 20 % par rapport au 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 réel 1m8.300s utilisateur 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench réel 0m3.370s utilisateur 0m3.353s sys 0m0.026s

Pour obtenir l'heure lors de la sélection d'une source TSC, on utilise l'instruction processeur RDTSC, dont l'exécution ne nécessite pas d'appel système (l'instruction ne nécessite pas de privilèges élevés et produit une valeur à partir du compteur de temps intégré au CPU). Par défaut, TSC n'est pas activé car autrefois cette source n'excluait pas la dérive temporelle progressive, qui dans d'autres processeurs est ajustée par logiciel pour obtenir des lectures plus précises. Selon un ingénieur spécialisé dans le développement de processeurs, les craintes concernant les décalages temporels lors de l'utilisation de TSC sont depuis longtemps fausses et, dans les processeurs modernes, cette source peut produire des lectures stables pendant des années.

Le passage des serveurs de production de Netflix vers une source TSC a entraîné une réduction de 43 % de la latence d'écriture et obtenu des résultats avec Ubuntu 4 fois plus rapides que les configurations exécutant CentOS avec une source de temps « xen ». Les résultats de l'étude ont été transférés à Amazon, qui a officiellement recommandé d'utiliser la source horaire TSC par défaut dans les environnements AWS EC2 basés sur l'hyperviseur Xen (kvm-clock reste recommandé dans les environnements basés sur l'hyperviseur Nitro).

Source: opennet.ru

Ajouter un commentaire