Brendan Gregg, a DTrace egyik fejlesztője, aki jelenleg BPF-alapú teljesítményelemző eszközöket fejleszt a Linux kernelben, összefoglalta a Netflix által a Cassandra DBMS-nek CentOS-ről Ubuntu. a Xen alapú Amazon EC2 felhő. Az átállás után a CPU terhelése 30%-kal nőtt, és az írási műveletek késése körülbelül ugyanennyivel nőtt. Mint kiderült, az intenzíven időinformációt kérő alkalmazások teljesítménye nagymértékben függ a rendszerben kiválasztott pontos időforrástól.
A teljesítménycsökkenés oka eleinte nem volt nyilvánvaló, és a diagnózis a top és execsnoop segédprogramok segítségével folyamatosan futó vagy időszakosan elindított, erőforrás-igényes rendszerfolyamatok lehetséges hatásainak figyelemmel kísérésével kezdődött. De minden arra utalt, hogy az erőforrás-felhasználás kifejezetten a Java nyelven írt Cassandra DBMS-ben nőtt. A CentOS-en és Ubuntu-n párhuzamosan futó, ugyanazokat a lekérdezéseket feldolgozó két Cassandra-folyamat profilozási mutatóinak összehasonlítása azt mutatta, hogy a teljes idő körülbelül 32%-át az os::javaTimeMillis() meghívásával töltöttük, ami az aktuális időről való információszerzésre szolgál. .
Ezt követően egy kísérletet végeztek, amelyben egy egyszerű Java alkalmazást írtak, amely ciklusban százmilliószor hívta meg a System.currentTimeMillis() metódust. Az alkalmazás futtatása azt mutatta, hogy CentOS-en 13 másodpercig, Ubuntu-n pedig körülbelül 68 másodpercig tartott, i.e. 5-ször lassabb. Hasonló programot írtak C-ben, amely százmilliószor hívta meg a gettimeofday() függvényt, de végrehajtva hasonló eredményeket kaptunk.
Mivel világossá vált, hogy a probléma forrása az aktuális idő visszaadási funkciója, a figyelem az indikátorok változásaira fordult a pontos idő különböző forrásainak rendszerben történő kiválasztásakor. A „/sys/devices/system/clocksource/clocksource0/current_clocksource” tartalma alapján az „xen” időzítő alapértelmezés szerint a Linux vendégrendszeren való futtatásakor használatos. Az időforrás "tsc"-re váltása után a tesztalkalmazás végrehajtási ideje Ubuntuban 68-ról 3.3 másodpercre csökkent, i.e. 20-szor gyorsabb lett. Ezenkívül elvégezték a kvm-óra időforrás teljesítménytesztjét, amely 20%-os késések növekedé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 $ idő java TimeBench valós 1m8.300s felhasználó 0m38.337s0 sys29.875. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ idő java TimeBench valós 0m3.370s felhasználó 0m3.353s sys 0m0.026s
A TSC forrás kiválasztásánál az idő megszerzéséhez az RDTSC processzor utasítást használjuk, melynek végrehajtása nem igényel rendszerhívást (az utasítás nem igényel emelt jogosultságokat, és a CPU-ba épített időszámlálóból állít elő értéket). Alapértelmezés szerint a TSC nincs aktiválva, mert régen ez a forrás nem zárta ki a fokozatos időeltolódást, amit más processzorokban szoftverrel állítanak be a pontosabb leolvasás érdekében. Egy processzorfejlesztésre szakosodott mérnök szerint a TSC használatakor az időeltolódásokkal kapcsolatos félelmek régóta nem igazak, és a modern processzorokban ez a forrás évekig stabil leolvasást produkálhat.
A Netflix éles szervereinek TSC-forrásra váltása 43%-kal csökkentette az írási késleltetést, és az Ubuntu használatával olyan eredményeket ért el, amelyek 4-szer gyorsabbak voltak, mint a CentOS-t futtató konfigurációk „xen” időforrással. A vizsgálat eredményeit átvitték az Amazonhoz, amely hivatalosan az alapértelmezett TSC időforrás használatát javasolta az AWS EC2 környezetekben a Xen hypervisor alapján (a kvm-óra továbbra is ajánlott a Nitro hypervisoron alapuló környezetben).
Forrás: opennet.ru