Brendan Gregg, jeden z vývojářů DTrace, který v současnosti vyvíjí nástroje pro analýzu výkonu založené na BPF v linuxovém jádře, shrnul zkušenosti získané při analýze problémů s výkonem, se kterými se Netflix setkal při migraci Cassandra DBMS z prostředí CentOS do prostředí Ubuntu. cloud Amazon EC2 založený na Xenu. Po migraci se zátěž CPU zvýšila o 30 % a zpoždění při operacích zápisu se zvýšilo přibližně o stejnou hodnotu. Jak se ukazuje, výkon aplikací, které intenzivně požadují informace o čase, velmi závisí na přesném časovém zdroji zvoleném v systému.
Zpočátku nebyl důvod poklesu výkonu zřejmý a diagnostika začala sledováním možného dopadu neustále běžících nebo periodicky spouštěných systémových procesů náročných na zdroje pomocí top a execsnoop utilit. Ale vše nasvědčovalo tomu, že spotřeba zdrojů vzrostla konkrétně v Cassandra DBMS napsané v Javě. Porovnání profilovacích metrik dvou procesů Cassandra běžících paralelně na CentOS a Ubuntu, zpracovávajících stejné dotazy, ukázalo, že asi 32 % z celkového času bylo vynaloženo na volání os::javaTimeMillis(), která se používá k získání informací o aktuálním čase. .
Poté byl proveden experiment, ve kterém byla napsána jednoduchá Java aplikace, která stomilionkrát ve smyčce volala metodu System.currentTimeMillis(). Spuštění aplikace ukázalo, že dokončení trvalo 13 sekund na CentOS a asi 68 sekund na Ubuntu, tzn. 5x pomaleji. Podobný program byl napsán v C, který volal funkci gettimeofday() sto milionkrát, ale při spuštění byly získány podobné výsledky.
Protože se ukázalo, že zdrojem problému je funkce vracení aktuálního času, pozornost se při výběru různých zdrojů přesného času v systému obrátila na změny ukazatelů. Soudě podle obsahu „/sys/devices/system/clocksource/clocksource0/current_clocksource“ byl časovač „xen“ standardně používán při spouštění Linuxu v hostujícím systému. Po změně zdroje času na „tsc“ se doba provádění testovací aplikace v Ubuntu snížila z 68 na 3.3 sekundy, tzn. bylo to 20krát rychlejší. Dodatečně byl proveden výkonnostní test zdroje času kvm-clock, který ukázal nárůst zpoždění o 20 % ve srovnání s 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 reálný uživatel 1m8.300s 0m38.337s sys 0s 29.875m0 echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench real 3.370m0s uživatel 3.353m0s sys 0.026mXNUMXs
Pro získání času při výběru zdroje TSC se používá instrukce procesoru RDTSC, jejíž provedení nevyžaduje systémové volání (instrukce nevyžaduje zvýšená oprávnění a produkuje hodnotu z časového čítače zabudovaného v CPU). Ve výchozím nastavení není TSC aktivován, protože za starých časů tento zdroj nevylučoval postupný časový posun, který je u jiných procesorů upravován softwarově pro dosažení přesnějších údajů. Podle inženýra specializujícího se na vývoj procesorů jsou obavy z časových posunů při použití TSC dlouho nepravdivé a v moderních procesorech může tento zdroj produkovat stabilní hodnoty po léta.
Přepnutí produkčních serverů v Netflixu na zdroj TSC vedlo ke 43% snížení latence zápisu a dosáhlo výsledků pomocí Ubuntu, které byly 4krát rychlejší než konfigurace s CentOS se zdrojem času „xen“. Výsledky studie byly přeneseny do Amazonu, který oficiálně doporučil používat výchozí zdroj času TSC v prostředích AWS EC2 založených na hypervizoru Xen (kvm-clock zůstává doporučeno v prostředích založených na hypervisoru Nitro).
Zdroj: opennet.ru