Brendan Gregg, un dos desenvolvedores de DTrace, que actualmente está a desenvolver ferramentas de análise de rendemento baseadas en BPF no núcleo de Linux, resumiu a experiencia adquirida ao analizar os problemas de rendemento que atopou Netflix ao migrar o DBMS Cassandra de CentOS a Ubuntu. a nube Amazon EC2 baseada en Xen. Despois da migración, a carga da CPU aumentou un 30 % e os atrasos durante as operacións de escritura aumentaron aproximadamente na mesma cantidade. Polo que se ve, o rendemento das aplicacións que solicitan intensamente información horaria depende moito da fonte horaria exacta seleccionada no sistema.
Nun primeiro momento, o motivo da diminución do rendemento non era obvio e o diagnóstico comezou co seguimento do posible impacto dos procesos do sistema en execución constante ou lanzados periódicamente utilizando as utilidades top e execsnoop. Pero todo indicaba que o consumo de recursos aumentara especificamente no DBMS Cassandra, escrito en Java. Ao comparar as métricas de perfil de dous procesos de Cassandra que se executan en paralelo en CentOS e Ubuntu, procesando as mesmas consultas, mostrou que preto do 32% do tempo total pasou a chamar a os::javaTimeMillis(), que se usa para obter información sobre a hora actual. .
Despois disto, realizouse un experimento no que se escribiu unha sinxela aplicación Java que chamou o método System.currentTimeMillis() cen millóns de veces nun bucle. A execución da aplicación mostrou que tardou 13 segundos en completarse en CentOS e uns 68 segundos en Ubuntu, é dicir. 5 veces máis lento. Escribiuse un programa similar en C que chamou á función gettimeofday() cen millóns de veces, pero cando se executou, obtivéronse resultados similares.
Dado que quedou claro que a orixe do problema era a función de devolver a hora actual, a atención volveuse aos cambios nos indicadores ao elixir diferentes fontes de tempo exacto no sistema. A xulgar polo contido de "/sys/devices/system/clocksource/clocksource0/current_clocksource", o temporizador "xen" utilizouse por defecto cando se executaba Linux no sistema convidado. Despois de cambiar a fonte de tempo a "tsc", o tempo de execución da aplicación de proba en Ubuntu diminuíu de 68 a 3.3 segundos, é dicir. fíxose 20 veces máis rápido. Ademais, realizouse unha proba de rendemento da fonte de tempo do reloxo kvm, que mostrou un aumento dos atrasos nun 20% en comparación co 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 usuario 0m38.337s $ sys. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench real 29.875m0s usuario 0m3.370s sys 0m3.353s
Para obter o tempo ao seleccionar unha fonte TSC, utilízase a instrución do procesador RDTSC, cuxa execución non require unha chamada ao sistema (a instrución non require privilexios elevados e produce un valor a partir do contador de tempo integrado na CPU). Por defecto, TSC non está activado porque antigamente esta fonte non excluía a deriva temporal gradual, que noutros procesadores axusta o software para conseguir lecturas máis precisas. Segundo un enxeñeiro especializado no desenvolvemento de procesadores, os temores sobre os cambios de tempo cando se usa TSC non son certos e nos procesadores modernos esta fonte pode producir lecturas estables durante anos.
Cambiar os servidores de produción en Netflix a unha fonte TSC resultou nunha redución do 43 % na latencia de escritura e conseguiu resultados usando Ubuntu que foron 4 veces máis rápidos que as configuracións que executaban CentOS cunha fonte de tempo "xen". Os resultados do estudo foron transferidos a Amazon, que recomendou oficialmente usar a fonte de tempo TSC predeterminada en ambientes AWS EC2 baseados no hipervisor Xen (o reloxo kvm segue sendo recomendado en ambientes baseados no hipervisor Nitro).
Fonte: opennet.ru