Brendan Gregg, jeden z twórców DTrace, który obecnie opracowuje narzędzia do analizy wydajności oparte na BPF w jądrze Linuksa, podsumował doświadczenia zdobyte podczas analizowania problemów z wydajnością, które napotkał Netflix podczas migracji Cassandra DBMS z CentOS do Ubuntu. chmura Amazon EC2 oparta na Xen. Po migracji obciążenie procesora wzrosło o 30%, a opóźnienia podczas operacji zapisu wzrosły o mniej więcej taką samą wartość. Jak się okazuje, wydajność aplikacji intensywnie żądających informacji o czasie w bardzo dużym stopniu zależy od dokładnego źródła czasu wybranego w systemie.
Początkowo przyczyna spadku wydajności nie była oczywista i diagnozę rozpoczęto od monitorowania możliwego wpływu stale działających lub okresowo uruchamianych procesów systemowych wymagających dużych zasobów za pomocą narzędzi top i execsnoop. Ale wszystko wskazywało, że zużycie zasobów wzrosło szczególnie w systemie Cassandra DBMS napisanym w Javie. Porównanie wskaźników profilowania dwóch procesów Cassandry działających równolegle w CentOS i Ubuntu, przetwarzających te same zapytania, wykazało, że około 32% całkowitego czasu poświęcono na wywoływanie funkcji os::javaTimeMillis(), która służy do uzyskiwania informacji o bieżącym czasie .
Następnie przeprowadzono eksperyment, w którym napisano prostą aplikację w języku Java, która wywoływała metodę System.currentTimeMillis() sto milionów razy w pętli. Uruchomienie aplikacji pokazało, że jej ukończenie zajęło 13 sekund na CentOS i około 68 sekund na Ubuntu, tj. 5 razy wolniej. Podobny program został napisany w C, który wywoływał funkcję gettimeofday() sto milionów razy, ale po uruchomieniu otrzymywał podobne wyniki.
Ponieważ stało się jasne, że źródłem problemu jest funkcja zwracania aktualnego czasu, zwrócono uwagę na zmiany wskaźników przy wyborze różnych źródeł dokładnego czasu w systemie. Sądząc po zawartości „/sys/devices/system/clocksource/clocksource0/current_clocksource”, licznik czasu „xen” był domyślnie używany podczas uruchamiania Linuksa w systemie gościa. Po zmianie źródła czasu na „tsc” czas wykonania aplikacji testowej w Ubuntu spadł z 68 do 3.3 sekundy, tj. stało się 20 razy szybsze. Dodatkowo przeprowadzono test wydajności źródła czasu zegarowego kvm, który wykazał wzrost opóźnień o 20% w porównaniu do TSC. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ czas java TimeBench rzeczywisty 1m8.300s użytkownik 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ czas java TimeBench rzeczywisty 0m3.370s użytkownik 0m3.353s sys 0m0.026s
Do uzyskania czasu przy wyborze źródła TSC wykorzystywana jest instrukcja procesora RDTSC, której wykonanie nie wymaga wywołania systemowego (instrukcja nie wymaga podniesionych uprawnień i generuje wartość z licznika czasu wbudowanego w CPU). Domyślnie TSC nie jest aktywowane, gdyż dawniej to źródło nie wykluczało stopniowego dryfu czasu, co w innych procesorach jest korygowane programowo, aby uzyskać dokładniejsze odczyty. Według inżyniera specjalizującego się w rozwoju procesorów obawy o przesunięcia czasowe przy stosowaniu TSC są od dawna nieprawdziwe i w nowoczesnych procesorach źródło to może dawać stabilne odczyty przez lata.
Zamiana serwerów produkcyjnych w serwisie Netflix na źródło TSC zaowocowała zmniejszeniem opóźnień zapisu o 43% i osiągnięciem wyników przy użyciu Ubuntu, które były 4 razy szybsze niż konfiguracje z systemem CentOS ze źródłem czasu „xen”. Wyniki badania przekazano do firmy Amazon, która oficjalnie zaleciła używanie domyślnego źródła czasu TSC w środowiskach AWS EC2 opartych na hypervisorze Xen (zegar kvm pozostaje zalecany w środowiskach bazujących na hypervisorze Nitro).
Źródło: opennet.ru