Brendan Gregg, a developer of DTrace, who is now developing performance analysis tools based on BPF in the Linux kernel, summarized the experience gained while examining performance issues that Netflix faced when migrating the Cassandra database from CentOS to Ubuntu in Amazon EC2 cloud environments based on Xen. After the migration, CPU load increased by 30%, and latency for write operations increased by approximately the same amount. It turned out that the performance of applications that heavily query time information is highly dependent on the chosen time source in the system.
Initially, the cause of the performance degradation was not obvious, and diagnostics began by tracking the possible influence of always-running or periodically launched resource-intensive system processes using the top and execsnoop utilities. However, everything pointed to the fact that resource consumption increased specifically in the Cassandra database written in Java. A comparison of profiling metrics for two Cassandra processes running in parallel on CentOS and Ubuntu, handling the same queries, showed that approximately 32% of the total time was spent on the os::javaTimeMillis() call, which is used to obtain the current time information.
After that, an experiment was conducted in which a simple Java application was written that called the System.currentTimeMillis() method one hundred million times in a loop. Running the application showed that it took 13 seconds to execute in CentOS, while in Ubuntu it took about 68 seconds, i.e., five times slower. A similar program was written in C that called the gettimeofday() function one hundred million times, but similar results were obtained during its execution.
Mivel világossá vált, hogy a probléma forrása a jelenlegi időt visszaadó funkció, a figyelem a rendszer különböző pontos időforrásainak kiválasztásakor tapasztalt eltérések módosítására irányult. A «/sys/devices/system/clocksource/clocksource0/current_clocksource» tartalmának alapján a Linux indításakor a vendég rendszeren alapértelmezés szerint a «xen» időzítő volt használatban. Az «tsc» időforrásra való váltás után a tesztalkalmazás futási ideje Ubuntu alatt 68 másodpercről 3.3 másodpercre csökkent, azaz 20-szoros lett. Ezen kívül a kvm-clock időforrás teljesítménytesztje is elvégezhető volt, amely 20%-os lassulást mutatott a TSC-hez képest. $ 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
A TSC forrás kiválasztásakor az idő megszerzéséhez a RDTSC processzor utasítást használják, amelynek végrehajtása nem igényel rendszerhívást (az utasítás nem igényel emelt szintű jogosultságokat, és az integrált CPU időmérőből adja meg az értéket). Alapértelmezés szerint a TSC nem aktiválódik, mivel régebben ez a forrás nem zárta ki az idő fokozatos driftjét, amely más kezelőkben programozás útján van korrigálva a pontosabb mérések eléréséhez. A processzorok fejlesztésére szakosodott mérnök véleménye szerint a TSC használatával kapcsolatos időeltolódásokról való aggodalmak már régóta nem aktuálisak, és a modern processzorok ez a forrás évekig stabil értékeket szolgáltathat.
A TSC forrásra való áttérés szerverek a Netflixnél 43%-kal csökkentette a késleltetést a felvétel során, és az Ubuntu használatával olyan eredményeket ért el, amelyek 4-szer jobbak voltak a «xen» időforrással rendelkező CentOS konfigurációnál. A végzett kutatás eredményeit az Amazonnak adták át, amely hivatalosan ajánlotta, hogy az AWS EC2 Xen hypervisor-alapú környezetekben alapértelmezés szerint a TSC időforrást használják (a Nitro hypervisor-alapú környezetekben továbbra is a kvm-clock ajánlott).
Forrás: opennet.ru
