Mudou para uma instância mais rápida, mas o desempenho não aparece: onde olhar?

• A Netflix migrou um microserviço Java com uso intenso de CPU de m5.4xl (16 vCPU) para m5.12xl (48 vCPU)
• Como o número de vCPUs era 3 vezes maior, esperava-se aproximadamente 3 vezes mais desempenho, mas a taxa de processamento aumentou apenas 25%
  • Pior ainda, a latência caiu 50%, e tanto o padrão de CPU quanto o de latência ficaram muito mais "irregulares" (choppy)
• Um texto que organiza, até o nível mais baixo, a jornada para resolver isso

Processo de resolução

• Decidiram comparar o nó rápido com o nó lento
• Com Flame Graph e profiling da JVM (usando JFR - Java Flight Recorder), não foi possível identificar a diferença
• Como não havia nada estranho nos níveis de aplicação/OS/JVM, passaram a examinar os PMC (Performance Monitoring Counters, contadores PMU) fornecidos pela instância m5.12xl
• Um dos problemas era "False Sharing" — um padrão que surge quando 2 núcleos leem ou escrevem variáveis não relacionadas que compartilham a mesma linha de cache L1
  • No código do JDK, resolveram esse problema sem mudar a funcionalidade, apenas inserindo bytes de padding para alterar o layout dos dados
• Outro problema era "True Sharing" — leitura e escrita da mesma variável por várias threads/núcleos
  • Para resolver isso, evitaram escrever na variável compartilhada e contornaram o cache de superclasse secundária da JVM
• Depois de aplicar os dois patches, a velocidade ficou 3,5 vezes maior do que no início
• Durante a resolução desse problema, descobriram o bug JDK-8180450, que estava dormente havia 5 anos

Conclusão

• Existe uma tendência de considerar a JVM um ambiente de execução altamente otimizado, capaz de competir com linguagens orientadas a desempenho como C++
• Isso vale para a maioria das cargas de trabalho, mas, em cargas específicas, o comportamento pode ser afetado não só pela implementação da aplicação, como também pela própria implementação da JVM
• Neste caso, os PMC foram usados para encontrar e corrigir um gargalo no código nativo da JVM, elevando em mais de 3 vezes a taxa de processamento dessa carga de trabalho
• Para esse tipo de problema de desempenho, a capacidade de inspecionar a execução no nível da microarquitetura da CPU é a única solução
• O Intel vTune oferece insights valiosos mesmo apenas com os principais PMC expostos em instâncias como a m5.12xl
• Se todas as instâncias da nuvem oferecessem um conjunto abrangente de PMC junto com PEBS (Processor Event-Based Sampling), seria possível obter ganhos de desempenho ainda maiores com análises mais profundas

[roxie]

Nossa, sério...

[ragingwind]

Deve ter sido emocionante quando a hipótese foi validada e a correção funcionou.