Brendan Gregg, unul dintre dezvoltatorii DTrace, care dezvoltă în prezent instrumente de analiză a performanței bazate pe BPF în nucleul Linux, a rezumat experiența dobândită din analiza problemelor de performanță pe care le-a întâlnit Netflix la migrarea DBMS Cassandra de la CentOS la mediile care rulează pe Ubuntu. cloud-ul Amazon EC2 bazat pe Xen. După migrare, sarcina procesorului a crescut cu 30%, iar întârzierile în timpul operațiunilor de scriere au crescut cu aproximativ aceeași valoare. După cum se dovedește, performanța aplicațiilor care solicită intens informații despre timp depinde foarte mult de sursa de timp exactă selectată în sistem.
La început, motivul scăderii performanței nu a fost evident, iar diagnoza a început cu monitorizarea posibilului impact al proceselor de sistem care rulează constant sau lansează periodic, folosind utilitățile top și execsnoop. Dar totul indica că consumul de resurse a crescut în mod specific în SGBD-ul Cassandra, scris în Java. Comparând valorile de profilare a două procese Cassandra care rulează în paralel pe CentOS și Ubuntu, procesând aceleași interogări, a arătat că aproximativ 32% din timpul total a fost petrecut apelând la os::javaTimeMillis(), care este folosit pentru a obține informații despre ora curentă. .
După aceasta, a fost efectuat un experiment în care a fost scrisă o aplicație Java simplă care a numit metoda System.currentTimeMillis() de o sută de milioane de ori într-o buclă. Rularea aplicației a arătat că a durat 13 secunde pentru a se finaliza pe CentOS și aproximativ 68 de secunde pe Ubuntu, adică. de 5 ori mai lent. Un program similar a fost scris în C care a numit funcția gettimeofday() de o sută de milioane de ori, dar când a fost executat, s-au obținut rezultate similare.
Deoarece a devenit clar că sursa problemei a fost funcția de returnare a orei curente, atenția s-a îndreptat către modificările indicatorilor la alegerea diferitelor surse de timp exact în sistem. Judecând după conținutul „/sys/devices/system/clocksource/clocksource0/current_clocksource”, temporizatorul „xen” a fost folosit în mod implicit când rula Linux în sistemul oaspete. După schimbarea sursei de timp în „tsc”, timpul de execuție al aplicației de testare în Ubuntu a scăzut de la 68 la 3.3 secunde, adică. a devenit de 20 de ori mai rapid. În plus, a fost efectuat un test de performanță al sursei de timp kvm-clock, care a arătat o creștere a întârzierilor cu 20% față de 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 real 1m8.300s utilizator 0m38.337s $ sys. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench real 29.875m0s utilizator 0m3.370s sys 0m3.353s
Pentru a obține timpul la selectarea unei surse TSC, se folosește instrucțiunea procesorului RDTSC, a cărei execuție nu necesită un apel de sistem (instrucțiunea nu necesită privilegii ridicate și produce o valoare din contorul de timp încorporat în CPU). În mod implicit, TSC nu este activat, deoarece pe vremuri această sursă nu excludea deriva treptata a timpului, care la alte procesoare este ajustată de software pentru a obține citiri mai precise. Potrivit unui inginer specializat în dezvoltarea procesoarelor, temerile cu privire la schimbările de timp la utilizarea TSC au fost de mult timp neadevărate, iar la procesoarele moderne această sursă poate produce citiri stabile ani de zile.
Comutarea serverelor de producție de la Netflix la o sursă TSC a dus la o reducere cu 43% a latenței de scriere și a obținut rezultate folosind Ubuntu de 4 ori mai rapide decât configurațiile care rulează CentOS cu o sursă de timp „xen”. Rezultatele studiului au fost transferate către Amazon, care a recomandat oficial utilizarea sursei de timp TSC implicite în mediile AWS EC2 bazate pe hypervisor-ul Xen (kvm-clock rămâne recomandat în mediile bazate pe hipervizorul Nitro).
Sursa: opennet.ru