Análise do impacto sobre o desempenho da fonte de tempo selecionada no sistema

Brendan Gregg, um dos desenvolvedores do DTrace, agora desenvolve ferramentas para análise de desempenho baseadas em BPF no núcleo do Linux. Ele resumiu a experiência obtida ao analisar os problemas de desempenho que a Netflix enfrentou ao migrar seu banco de dados Cassandra do CentOS para o Ubuntu em ambientes executados na nuvem Amazon EC2 baseados em Xen. Após a migração, a carga na CPU aumentou em 30% e as latências ao executar operações de gravação aumentaram aproximadamente na mesma proporção. Descobriu-se que o desempenho das aplicações que consultam intensivamente informações de tempo depende muito da fonte de tempo exata escolhida pelo sistema.

Inicialmente, a causa da redução de desempenho não era óbvia e a investigação começou com o rastreamento do possível impacto de processos do sistema que consomem muitos recursos, que estão sempre em execução ou são iniciados periodicamente, utilizando as ferramentas top e execsnoop. Mas tudo indicava que o consumo de recursos havia aumentado especificamente no banco de dados Cassandra, escrito em Java. A comparação das métricas de perfilamento de dois processos Cassandra executados paralelamente no CentOS e no Ubuntu, processando as mesmas consultas, mostrou que cerca de 32% do tempo total era gasto na chamada os::javaTimeMillis(), utilizada para obter informações sobre a hora atual.

Em seguida, foi realizado um experimento no qual um aplicativo simples foi escrito em Java, chamando em um loop o método System.currentTimeMillis() cem milhões de vezes. A execução do aplicativo mostrou que no CentOS eram necessários 13 segundos, enquanto no Ubuntu o mesmo processo levou cerca de 68 segundos, ou seja, cinco vezes mais lento. Um programa similar foi escrito em C, chamando a função gettimeofday() cem milhões de vezes, mas obteve resultados semelhantes.

Uma vez que ficou claro que a função de retorno do tempo atual era a fonte do problema, a atenção se voltou para a alteração dos indicadores ao selecionar diferentes fontes de tempo preciso no sistema. De acordo com o conteúdo de "/sys/devices/system/clocksource/clocksource0/current_clocksource", por padrão, ao iniciar o Linux em um sistema convidado, o temporizador "xen" era utilizado. Após a troca da 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, ficou 20 vezes mais rápido. Adicionalmente, foi realizado um teste de desempenho com a fonte de tempo kvm-clock, que mostrou um aumento de latência de 20% em comparação com o 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 user 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench real 0m3.370s user 0m3.353s sys 0m0.026s

Para obter o tempo ao selecionar a fonte TSC, utiliza-se a instrução de processador RDTSC, cuja execução não requer uma chamada de sistema (a instrução não exige privilégios elevados e fornece um valor do contador de tempo embutido no CPU). Por padrão, o TSC não é ativado, pois nos tempos antigos, essa fonte não eliminava o drifts de tempo que, em outros manipuladores, eram corrigidos programaticamente para alcançar medições mais precisas. Segundo um engenheiro especializado em desenvolvimento de processadores, as preocupações sobre mudanças de tempo ao usar o TSC não são mais válidas e processadores modernos essa fonte pode fornecer medições estáveis por anos.

A transição para o TSC servidores na Netflix levou a uma redução de 43% na latência de gravação e, ao usar Ubuntu, alcançou resultados quatro vezes superiores à configuração com CentOS utilizando a fonte de tempo "xen". Os resultados do estudo realizado foram encaminhados à Amazon, que oficialmente recomendou que, em ambientes AWS EC2 baseados no hipervisor Xen, o TSC fosse usado como a fonte de tempo padrão (em ambientes baseados no hipervisor Nitro, a recomendação continua sendo o kvm-clock).

Fonte: opennet.ru

Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS 🔥 Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS | ProHoster