Mude uma coisa, meça de novo. Como encontrar o verdadeiro bottleneck

Quando uma plataforma está lenta, a nota de encomenda mais rápida é por mais de tudo. Muitas vezes ajuda um pouco, custa muito e deixa a verdadeira causa no lugar, pronta a voltar a morder no próximo pico de tráfego. A alternativa é menos entusiasmante e muito mais eficaz: encontrar o único recurso pelo qual a carga de trabalho está à espera, mudar uma coisa nesse recurso e medir de novo. Eis o método e as ferramentas.

Comece com um número, não com uma sensação

«O site está lento» não pode ser testado. «O checkout demora quatro segundos no pico da noite e menos de um de madrugada» pode. Antes de tocar em seja o que for, fixe o sintoma numa medição que possa repetir: um tempo de página medido de fora, a duração de uma query, o tempo de execução de um trabalho batch, uma taxa de pedidos a partir da qual os erros começam. Esse número é a forma de saber se alguma coisa que mudou ajudou. Sem ele, qualquer alteração parece progresso.

Depois escreva o percurso que a operação lenta percorre: cliente, rede, load balancer, servidor web, aplicação, cache, base de dados, storage. O bottleneck está algures nesse percurso, e o percurso diz-lhe onde procurar.

Verifique cada recurso quanto a uso, saturação e erros

Uma disciplina simples, popularizada por Brendan Gregg como método USE, mantém a procura honesta. Para cada recurso no percurso, CPU, memória, rede, storage, faça três perguntas: quão ocupado está, há trabalho em fila à espera dele, e está a reportar erros? Um recurso pode estar pouco utilizado e ainda assim ser o problema se os pedidos se acumulam à sua frente, por isso a segunda pergunta é a que mais conta.

CPU.

mpstat -P ALL 1
vmstat 1
pidstat -u 1

Olhe para o uso por core, não apenas para a média. Um core em carga total enquanto os restantes estão parados aponta para um bottleneck single-threaded que mais cores não vão resolver. No vmstat, uma run queue (r) persistentemente maior do que o número de cores é saturação.

Memória.

free -h
vmstat 1
cat /proc/pressure/memory

A pressão de memória aparece como atividade de reclaim e tempo de stall no ficheiro de pressure. Numa máquina virtual bem construída não há swap onde esconder, por isso uma carga de trabalho que precisa genuinamente de mais memória do que tem falha de forma audível, que é o resultado honesto: a correção é mais memória ou uma aplicação mais contida.

Storage.

iostat -x 1
pidstat -d 1

As colunas que contam são os tempos médios de espera para leituras e escritas e o tamanho da fila. O %util engana em volumes flash e SAN, que servem muitos pedidos em paralelo e podem mostrar utilização alta enquanto ainda têm margem de sobra. Tempos de espera a subir com uma fila a crescer são o sinal real.

Rede.

sar -n DEV 1
sar -n EDEV 1
ss -s
cat /proc/net/bonding/bond0
ethtool -S <interface> | grep -iE 'drop|err|discard'

Compare o tráfego por membro de um bond: um membro ocupado enquanto o outro está parado é um problema de hashing, não de largura de banda. Drops e erros nos contadores da interface apontam para baixo do sistema operativo, para cabos, ótica ou o switch.

Base de dados. Muitas plataformas lentas são uma base de dados a ler do disco o que devia estar a ler da memória. Em MySQL ou MariaDB, compare as leituras lógicas com as leituras que tiveram de ir ao storage:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

Se Innodb_buffer_pool_reads (leituras que falharam a memória) cresce depressa em relação a Innodb_buffer_pool_read_requests, o working set não cabe no buffer pool. O slow query log, com um limiar sensato, diz-lhe que queries estão a pagar por isso.

Mude uma coisa

Quando um recurso se destaca, formule uma hipótese que explique o número original e faça uma única alteração que a teste: um buffer pool dimensionado ao working set, uma política de hash para o bond, uma cache à frente da página cara, uma query com o índice de que precisa, uma VM redimensionada para caber num só socket de CPU. Uma alteração de cada vez, porque se mudar três coisas e o número melhorar, não sabe qual delas ajudou, e pode ter ficado com duas que pioraram as coisas.

Meça de novo, da mesma forma

Repita a medição desde o início, nas mesmas condições: a mesma hora do dia ou a mesma carga sintética, o mesmo teste, as mesmas ferramentas. Uma alteração que não ajudou continua a ser um resultado, porque exclui alguma coisa. Reverta-a e volte aos recursos.

Repita até o sintoma original desaparecer ou até o bottleneck seguinte ser algo que o dinheiro deve mesmo resolver. É nessa altura que comprar hardware é a resposta certa, e saberá exatamente que recurso comprar.

Como é na prática

Algumas das configurações mais eficazes têm uma linha. Dimensionamos os buffers de memória das bases de dados para que os dados quentes vivam em RAM e o flash sirva trabalho real, e cada servidor com bond que construímos faz hash sobre endereços e portas para que ambas as ligações transportem tráfego. As duas são regras fixas em todas as plataformas que gerimos.

Como o fazemos

O trabalho de desempenho é a forma como operamos todas as plataformas que gerimos, não um produto à parte. Medimos em todas as camadas, do I/O por volume nos arrays e dos contadores por porta em bonds e switches até aos slow logs nas bases de dados e aos tempos medidos de fora para dentro através do CDN, antes de nomear uma causa. Regras fixas que estão fiavelmente certas, como bonds que usam as duas ligações, flash tratado como flash e VMs que cabem dentro de um socket, aplicam-se a todas as construções. Quando uma plataforma precisa mesmo de mais capacidade, dizemos-lhe que recurso, quanto e porquê.

Se a sua plataforma está lenta e a única sugestão até agora foi um servidor maior, deixe-nos medi-la primeiro.

Fale com um engenheiro

Related

Relacionados: Engenharia de desempenho e capacidade · Bare metal servers em HPE e Dell · Storage SAN enterprise em HPE 3PAR, all-flash