Brendan Gregg, um dos desenvolvedores do DTrace, que atualmente está desenvolvendo ferramentas de análise de desempenho baseadas em BPF no kernel Linux, resumiu a experiência adquirida ao analisar os problemas de desempenho que a Netflix encontrou ao migrar o SGBD Cassandra do CentOS para o Ubuntu. a nuvem Amazon EC2 baseada em Xen. Após a migração, a carga da CPU aumentou 30% e os atrasos durante as operações de gravação aumentaram aproximadamente na mesma proporção. Acontece que o desempenho de aplicativos que solicitam intensamente informações de tempo depende muito da fonte exata de tempo selecionada no sistema.
A princípio, o motivo da diminuição do desempenho não era óbvio e o diagnóstico começou com o monitoramento do possível impacto de processos de sistema com uso intensivo de recursos em execução constante ou lançados periodicamente usando os utilitários top e execsnoop. Mas tudo indicava que o consumo de recursos havia aumentado especificamente no SGBD Cassandra, escrito em Java. Comparando as métricas de criação de perfil de dois processos Cassandra executados em paralelo no CentOS e no Ubuntu, processando as mesmas consultas, mostrou que cerca de 32% do tempo total foi gasto chamando os::javaTimeMillis(), que é usado para obter informações sobre o horário atual .
Depois disso, foi realizado um experimento no qual foi escrita uma aplicação Java simples que chamava o método System.currentTimeMillis() cem milhões de vezes em um loop. A execução do aplicativo mostrou que demorou 13 segundos para ser concluído no CentOS e cerca de 68 segundos no Ubuntu, ou seja, 5 vezes mais lento. Um programa semelhante foi escrito em C que chamou a função gettimeofday() cem milhões de vezes, mas quando executado, resultados semelhantes foram obtidos.
Como ficou claro que a origem do problema era a função de retornar a hora atual, a atenção se voltou para as mudanças nos indicadores ao escolher diferentes fontes de hora exata no sistema. A julgar pelo conteúdo de “/sys/devices/system/clocksource/clocksource0/current_clocksource”, o temporizador “xen” foi usado por padrão ao executar o Linux no sistema convidado. Após alterar a fonte de tempo para “tsc”, o tempo de execução do aplicativo de teste no Ubuntu diminuiu de 68 para 3.3 segundos, ou seja, tornou-se 20 vezes mais rápido. Adicionalmente, foi realizado um teste de desempenho da fonte de tempo kvm-clock, que mostrou um aumento de 20% nos atrasos em relação ao 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 usuário 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ tempo java TimeBench real 0m3.370s usuário 0m3.353s sys 0m0.026s
Para obter o tempo ao selecionar uma fonte TSC, é utilizada a instrução do processador RDTSC, cuja execução não requer uma chamada de sistema (a instrução não requer privilégios elevados e produz um valor do contador de tempo embutido na CPU). Por padrão, o TSC não está ativado porque antigamente essa fonte não excluía o desvio gradual do tempo, que em outros processadores é ajustado por software para obter leituras mais precisas. De acordo com um engenheiro especializado em desenvolvimento de processadores, os temores sobre mudanças de tempo ao usar o TSC há muito são falsos e em processadores modernos esta fonte pode produzir leituras estáveis por anos.
A troca de servidores de produção da Netflix para uma fonte TSC resultou em uma redução de 43% na latência de gravação e alcançou resultados usando o Ubuntu que foram 4 vezes mais rápidos do que configurações executando CentOS com uma fonte de tempo “xen”. Os resultados do estudo foram transferidos para a Amazon, que recomendou oficialmente o uso da fonte de tempo TSC padrão em ambientes AWS EC2 baseados no hipervisor Xen (kvm-clock permanece recomendado em ambientes baseados no hipervisor Nitro).
Fonte: opennet.ru