Geralmente, uma instalação do nosso aplicativo baseado no Debian, estável no local, é executado em uma máquina virtual - normalmente no VMware ESXi. No caso geral, não temos visibilidade ou influência sobre o ambiente de virtualização e não temos acesso a, e. o cliente VMware vCenter ou equivalente. Eu me concentro no VMware aqui, porque de longe é o mais comum que vemos.
Gostaríamos de:
- Diga ao administrador do VMware de um cliente: você pode executar nosso aplicativo em, por exemplo, seu ambiente VMware ESX, desde que atenda aos critérios de desempenho X, Y e Z.
- Ser capaz de determinar se os critérios X, Y e Z são de fato atendidos continuamente (por exemplo, agora ), mesmo em um sistema em execução (não podemos parar nossa aplicação e executar benchmarks, e um o benchmark inicial não será suficiente, já que o desempenho em ambientes virtuais muda com o tempo).
- Ter confiança de que, se os critérios X, Y e Z forem atendidos, teremos recursos HW virtuais adequados para executar nosso aplicativo com desempenho satisfatório.
Agora, quais são X, Y e Z?
Temos visto várias vezes que, quando há problemas de desempenho, o problema não está em nosso aplicativo, mas no ambiente de virtualização. Por exemplo. outra máquina virtual usa toneladas de CPU, memória ou a SAN na qual os discos são realmente armazenados e usam muito além de nosso aplicativo. Atualmente, não temos como provar ou refutar isso.
Teoricamente, também pode ser possível que às vezes nossa aplicação seja lenta ...; -)
Como alguém determina a causa raiz de nossos problemas de desempenho: ambiente virtual ou nossa aplicação?
Existem normalmente 3 áreas para problemas de desempenho: CPU, Memória e E / S de DISCO.
CPU
Em p. VMware, o administrador pode especificar Reserva e Limite, expresso em MHz, mas é, por exemplo, 512 MHz em um host ESX exatamente o mesmo que 512 MHz em outro host ESX, possivelmente em um cluster ESX completamente diferente?
E como se mede se realmente conseguimos isso? Enquanto nosso aplicativo está em execução, talvez possamos ver que estamos com 212% de utilização da CPU em 4 CPUs. Isso é porque nosso aplicativo está fazendo muito ou porque outra VM no mesmo host está executando uma tarefa intensiva da CPU e usando toda a CPU?
Memória (Balonismo?)
Se pedirmos por exemplo 16 GB de RAM, que geralmente é configurado, mas devido ao balão , na verdade, só recebemos 4 GB e surpresa, nosso aplicativo tem um desempenho ruim.
Pode-se perguntar às ferramentas da VMware sobre o balão atual, mas descobrimos que isso geralmente acontece (ou é impreciso pelo menos). Vimos exemplos em que o SO acha que há 16 GB de RAM total, a soma da memória residente (RSS) de todos os processos é de 4 GB RAM, mas há apenas 2 GB de RAM livre, mesmo quando as ferramentas VMware nos dizem que há 0 balão: - (
Além disso, adicionar RSS juntos não é válido, pois pode haver RAM compartilhada facilmente, por exemplo, memória copy-on-write de modo que 512MB + 512MB não significa necessariamente 1GB, mas pode significar algo menos. Portanto, não se pode simplesmente subtrair o RSS de todos os processos para obter uma medida de quanto a RAM deve ser livre e, assim, detectar o balão de maneira confiável. Pode-se detectar alguns casos de balonismo, mas existem outros casos em que o balonismo está em vigor, mas não é detectável por este método.
E / S de disco
Acho que poderíamos representar graficamente, ao longo do tempo, o número de leituras e gravações em disco, o número de bytes lidos e gravados e o IO wait%. Mas isso nos dará uma imagem precisa do disco I / O? Eu imagino que se houver um minerador de bitcoin rodando em outra VM usando todo o CPU, nosso% de Espera de IO irá aumentar, mesmo se a SAN subjacente der exatamente o mesmo desempenho, simplesmente porque nossos recursos de CPU caem e, portanto, IO espera que é medido em% ) aumenta.
Então, em resumo, que linguagem podemos usar para descrever, por exemplo, um administrador VMware, qual o desempenho que precisamos, de forma portátil e mensurável?
