Brendan Gregg, uno degli sviluppatori di DTrace, che attualmente sta sviluppando strumenti di analisi delle prestazioni basati su BPF nel kernel Linux, ha riassunto l'esperienza acquisita analizzando i problemi di prestazioni riscontrati da Netflix durante la migrazione del DBMS Cassandra da CentOS a Ubuntu negli ambienti in esecuzione su. il cloud Amazon EC2 basato su Xen. Dopo la migrazione, il carico della CPU Γ¨ aumentato del 30% e i ritardi durante le operazioni di scrittura sono aumentati all'incirca della stessa quantitΓ . A quanto pare, le prestazioni delle applicazioni che richiedono intensamente informazioni sull'ora dipendono molto dall'esatta fonte dell'ora selezionata nel sistema.
Inizialmente, il motivo del calo delle prestazioni non era ovvio e la diagnosi Γ¨ iniziata con il monitoraggio del possibile impatto di processi di sistema ad alta intensitΓ di risorse costantemente in esecuzione o avviati periodicamente utilizzando le utilitΓ top ed execsnoop. Ma tutto indicava che il consumo di risorse era aumentato proprio nel DBMS Cassandra, scritto in Java. Confrontando le metriche di profilazione di due processi Cassandra in esecuzione in parallelo su CentOS e Ubuntu, elaborando le stesse query, Γ¨ emerso che circa il 32% del tempo totale Γ¨ stato impiegato chiamando os::javaTimeMillis(), che viene utilizzato per ottenere informazioni sull'ora corrente .
Successivamente Γ¨ stato condotto un esperimento in cui Γ¨ stata scritta una semplice applicazione Java che ha chiamato il metodo System.currentTimeMillis() cento milioni di volte in un ciclo. L'esecuzione dell'applicazione ha mostrato che ci sono voluti 13 secondi per essere completata su CentOS e circa 68 secondi su Ubuntu, ad es. 5 volte piΓΉ lento. Un programma simile Γ¨ stato scritto in C che ha chiamato la funzione gettimeofday() un centinaio di milioni di volte, ma una volta eseguito si sono ottenuti risultati simili.
PoichΓ© Γ¨ diventato chiaro che la fonte del problema era la funzione di restituzione dell'ora corrente, l'attenzione si Γ¨ rivolta ai cambiamenti negli indicatori quando si scelgono diverse fonti di ora esatta nel sistema. A giudicare dal contenuto di "/sys/devices/system/clocksource/clocksource0/current_clocksource", il timer "xen" veniva utilizzato per impostazione predefinita durante l'esecuzione di Linux nel sistema ospite. Dopo aver modificato la sorgente dell'ora in "tsc", il tempo di esecuzione dell'applicazione di prova in Ubuntu Γ¨ diminuito da 68 a 3.3 secondi, ovvero Γ¨ diventato 20 volte piΓΉ veloce. Inoltre Γ¨ stato effettuato un test delle prestazioni della sorgente temporale kvm-clock, che ha mostrato un aumento dei ritardi del 20% rispetto a 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 utente 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench real 0m3.370s utente 0m3.353s sys 0m0.026s
Per ottenere l'ora quando si seleziona una sorgente TSC, viene utilizzata l'istruzione del processore RDTSC, la cui esecuzione non richiede una chiamata di sistema (l'istruzione non richiede privilegi elevati e produce un valore dal contatore del tempo integrato nella CPU). Per impostazione predefinita, il TSC non Γ¨ attivato perchΓ© in passato questa fonte non escludeva la deriva temporale graduale, che in altri processori viene regolata dal software per ottenere letture piΓΉ accurate. Secondo un ingegnere specializzato nello sviluppo di processori, i timori relativi agli spostamenti temporali quando si utilizza il TSC sono da tempo falsi e nei processori moderni questa fonte puΓ² produrre letture stabili per anni.
Il passaggio dei server di produzione di Netflix a una sorgente TSC ha comportato una riduzione del 43% della latenza di scrittura e ha ottenuto risultati utilizzando Ubuntu 4 volte piΓΉ veloci rispetto alle configurazioni che eseguono CentOS con una sorgente temporale "xen". I risultati dello studio sono stati trasferiti ad Amazon, che ha ufficialmente raccomandato l'utilizzo della sorgente temporale TSC predefinita negli ambienti AWS EC2 basati sull'hypervisor Xen (kvm-clock rimane consigliato negli ambienti basati sull'hypervisor Nitro).
Fonte: opennet.ru