Home Artigos técnicos Otimização de servidor em escala: Eliminando pacotes e melhorando a capacidade
Applications

Otimização de servidor em escala: Eliminando pacotes e melhorando a capacidade

About The Author

Outline

Melhorar o desempenho de nossa tecnologia para o benefício de nossos clientes e de seus públicos é um curso contínuo de ação na Verizon Media, agora Edgio. Por exemplo, nos últimos dois anos, nossos engenheiros de desempenho e kernel eliminaram praticamente todas as quedas de pacotes (mais de 98% removidos), melhoraram as verificações de integridade de desempenho em nossos servidores de borda em 50% e aumentaram a capacidade do servidor em até 40%.

Nós também juntamos o acima com automação de rede e expansão de rede orgânica – atualmente mais de 250 Tbps – para melhorar a experiência do usuário. Ajustar cuidadosamente nosso desempenho desempenhou um papel importante em nossa capacidade de suportar picos de rede em rápida mudança e, às vezes, imprevisíveis, à medida que entregamos atualizações de software para milhões de consoles de jogos, transmissões de vídeo ao vivo para grandes eventos esportivos e quando balanceadores de carga multi-CDN movem a carga para nossa rede.

Manter a qualidade em escala envolve otimizar o desempenho em todas as partes da pilha de tecnologia da Edgio Media Platform: De suas camadas mais baixas, na CPU e na NIC, até o SO e os aplicativos. Em última análise, o nosso objetivo é sempre o mesmo: Excelente desempenho. Para chegar lá, realizamos análises baseadas em dados, contando com mudanças mensuráveis de desempenho para validar nossa tomada de decisão.

Otimizações de cache da CPU

Nós executamos 20 000 servidores em todo o mundo, em grande parte chipsets Broadwell e Haswell, tipicamente com 32 a 40 núcleos. Nós adicionamos 12 000 servidores apenas nos últimos três anos. No entanto, a maioria dos servidores não é otimizada para escalar nossas cargas de trabalho fora da caixa. Simplesmente adicionar mais servidores não torna a operação mais eficiente e pode criar desafios adicionais. O dimensionamento eficaz requer uma otimização cuidadosa dos componentes existentes. Ser capaz de otimizar um servidor para que ele seja capaz de processar duas ou três vezes (ou mais) solicitações do que com a configuração padrão pode fazer uma diferença poderosa para o desempenho geral da rede.

A mudança do snoop inicial para o snoop home

CPUs modernas empregam um protocolo snoop para garantir que o cache local da CPU seja consistente com a memória. Isso permite que os caches ouçam modificações em variáveis em qualquer CPU e atualizem suas versões dessas variáveis de acordo. Não surpreendentemente, a técnica específica usada pode impactar significativamente o desempenho da memória.

Por padrão, nossos fornecedores de hardware usam um protocolo chamado Early Snoop. Ele tem uma latência mais baixa para resolver a coerência do cache, pois todos os núcleos podem fazer solicitações de coerência do cache simultaneamente e enviar transmissões. Descobrimos que nossos sistemas geram grandes quantidades de atividade simultânea de disco e NIC durante cenários de pico de carga. Essas atividades resultam em altas transmissões de snoop, levando a gargalos de comunicação. Isso faz com que o dispositivo de E/S diminua e, eventualmente, pode levar ao processamento parar completamente.

Ao mudar para o modo Home Snoop, uma abordagem que coalesce solicitações de snoop, vimos uma redução significativa no tráfego de transmissão. O Quick Path Interconnect (QPI) do processador não está mais faminto durante períodos de operações simultâneas de E/S de disco pesado e de rede; além disso, as quedas de pacotes que vimos com o Early Snoop significativamente reduzidas em número.

Alterar o protocolo snoop depende simplesmente de alterar uma configuração do BIOS. No entanto, reiniciar servidores 20 000 sem interromper os clientes requer automação. Podemos fazer com que esse tipo de mudança de implantação em larga escala funcione na produção, em parte graças à nossa plataforma de AUTOMAÇÃO DE TI baseada no StackStorm, o Crayfish.

Um evento de failover inesperado

Ao testar a mudança para o Home Snoop, ocorreu um failover: Um de nossos maiores clientes de mídia, que tem uma implantação de vários CDN, experimentou um problema com outro fornecedor e moveu uma parte significativa do tráfego para nosso CDN. Isso proporcionou a oportunidade de testar as melhorias em larga escala do Home Snoop, que foram extremamente impactantes.

A figura acima mostra o efeito da mudança. O grupo que ainda usava o Snoop cedo viu um aumento de quedas em 13.75x (55K pacotes drops por servidor por dia), enquanto o grupo que tinha mudado para o Home Snoop viu um aumento de apenas 4,23x (27K pacotes drops por máquina por dia). Home Snoop imediatamente provou seu valor durante o evento de failover.

Otimização da interface de rede e afinações do driver

Outro conjunto de ajustes importantes de desempenho envolveu a interface de rede e o driver. Aqui, nós nos concentramos em reduzir as quedas de pacotes geralmente ocorrendo com o tráfego de explosão. Durante grandes eventos, o tráfego de entrada era tão pesado que o NIC não conseguia manter-se, e vimos quedas de pacotes mais cedo do que o esperado. À medida que investigamos o porquê, encontramos vários parâmetros na própria NIC necessários para ajustar, incluindo o número de filas, o tamanho da fila e o agendamento de interrupções. Para otimizar essas especificações para a nossa carga de trabalho e configuração de hardware específica, concentramo-nos em ajustar o RSS (Receive Side Scaling), tornando as filas de entrada mais longas, reduzindo seu número geral e equilibrando as interrupções nos nós NUMA.

O gráfico acima mostra um teste que executamos na América do Norte, no qual cada pop é dividido em um grupo de controle (ou seja, untuned) e um grupo de teste (ou seja, tuned). Aqui, apresentamos o número de gotas somadas diariamente durante uma semana. Após as afinações, nosso grupo de testes viu aproximadamente 95% menos quedas de pacotes do que o grupo de controle, permitindo que mais solicitações fossem processadas. Isso também significa que é necessária menos ação para gerenciar manualmente a saúde da rede durante os surtos, deixando nossos engenheiros livres para se concentrar em outras áreas.

Sintonizações de programação da CPU

Enquanto o ajuste de nível de driver e NIC se concentraram em melhorar a capacidade total que podemos oferecer, as afinações de programação de CPU concentraram-se em melhorar a forma como podemos fornecer conteúdo de forma consistente.

Sem essas afinações, as mensagens de entrada e saída têm que competir por recursos. Quando começamos a investigar a causa raiz, descobrimos que a contenção sobre recursos resultou de como o kernel estava programando o manuseio dessas mensagens. Isso significava que a carga não foi migrada durante o pico de tráfego até que as CPUs em questão estivessem saturadas. Para corrigir isso, definimos a afinidade da CPU dos nossos processos de servidor web para excluir CPUs dedicadas ao processamento de tráfego de rede de entrada.

Os gráficos acima mostram o impactos de ativar as afinações de programação da CPU globalmente em toda a CDN de 21 a 22 de março. Avaliamos o impactos com base no percentil 95 e nos valores medianos de uma métrica de verificação de integridade de desempenho, uma métrica composta demonstrando o tempo de resposta relativo de um servidor. Como esperado, os vales de baixo tráfego não foram significativamente reduzidos; no entanto, os picos revelam uma contenção significativamente reduzida entre o tráfego de entrada e de saída. Isso se traduz em uma grande melhoria tanto nos outliers quanto nos medianos, particularmente durante as cargas de pico. Agora, podemos lidar melhor com picos de tráfego e problemas relacionados ao alto comportamento de outlier, como rebuffers em fluxos de vídeo ou a capacidade de resposta geral de um servidor para todos os usuários.

Atualizações de desempenho do kernel

Otimizar as camadas superiores da nossa pilha de tecnologia é igualmente tão importante quanto ajustar os elementos da camada inferior. No processo de atualização recente do nosso sistema operacional, também atualizamos nossos kernels Linux para aproveitar o trabalho de engenharia upstream da comunidade de kernel Linux. O novo kernel teve cerca de quatro anos de desenvolvimento além da versão anterior implantada, incluindo melhorias no sistema de gerenciamento de memória, o que reduz alocações de páginas de bloqueio e melhora a distribuição de carga e o desempenho ao usar a API epoll e o sharding de soquete.

No gráfico acima, você pode ver o efeito do processo de atualização do final de novembro para o início de janeiro como um declínio nas verificações de integridade de desempenho do percentil 99. As melhorias subjacentes do kernel levaram a uma distribuição de carga mais uniforme em todos os nossos processadores de solicitação de servidor web. Isso resultou em uma queda substancial nesses outliers, tornando os pedidos para todos os nossos clientes mais confiáveis.

Afinações de desempenho têm um efeito significativo

Nos últimos dois anos, as afinações de longo alcance do sistema que o desempenho e a engenharia do kernel implantaram eliminaram praticamente todas as quedas de pacotes (mais de 98% removidas) e reduziu pela metade nossas verificações de integridade de desempenho em nossos servidores de borda. Nossa capacidade de servidor aumentou de 10 a 40% (o valor exato varia de acordo com o perfil do cliente e evento), permitindo-nos entregar mais tráfego mais rápido. O comportamento outlier melhorou significativamente, tornando-se uma experiência mais consistente, e temos visto uma boa melhoria nas medianas, particularmente durante a carga máxima. Em resumo, o ajuste de desempenho para toda a pilha de tecnologia nos permitiu lidar melhor com quaisquer picos de tráfego inesperados (seja de uma atualização de console de jogos muito antecipada ou um popular evento de streaming de vídeo ao vivo) e oferecer um desempenho mais consistente para todos os nossos usuários.