Diagnóstico de CPU steal time em hosts Linux virtualizados com mpstat e vmstat

Objetivo

Distinguir o esgotamento real de CPU do tempo que a vCPU de uma máquina virtual passou esperando que o host a escalonasse, antes de buscar uma correção na aplicação que não pode existir.

Pré-requisitos

Um guest Linux executado sob um hypervisor (KVM, Xen, VMware ou uma VM de nuvem) que exponha ao guest um relógio de steal time (KVM e Xen expõem; nem todo hypervisor ou kernel de guest o reporta). É preciso ter o pacote sysstat para o mpstat e o procps para o vmstat, ambos normalmente já instalados ou instaláveis de forma não interativa (DEBIAN_FRONTEND=noninteractive apt-get install -y sysstat / dnf install -y sysstat).

Passos

1. Obtenha o detalhamento por CPU em uma janela curta: mpstat -P ALL 1 5. O manual do sysstat define %steal como a porcentagem de tempo de espera involuntária da CPU virtual enquanto o hypervisor atendia outro processador virtual. Ou seja, é tempo em que o kernel do guest queria executar mas não pôde, e não tempo em que ele fez algum trabalho.
2. Confira com uma segunda ferramenta: vmstat 1 5. A coluna st está documentada como o tempo roubado de uma máquina virtual; ela deve acompanhar, aproximadamente, o %steal da linha all do mpstat. Ignore a primeira linha do vmstat, que é a média desde o boot, e não o intervalo atual.
3. Leia o padrão, não só o número: steal distribuído de forma uniforme por todas as CPUs durante o intervalo sugere contenção de escalonamento em todo o host; steal que só aparece enquanto a sua própria carga está limitada por CPU sugere que o host está sobrealocado para esse perfil de carga. O steal só se acumula enquanto uma vCPU tem trabalho para executar, de modo que um guest quase ocioso mostra pouco steal, mesmo em um host ocupado.
4. Trate o problema como uma questão de posicionamento ou capacidade, não como um bug de código: nada no guest consegue mostrar o que as outras máquinas virtuais do host estavam fazendo naquele momento. Um steal sustentado e relevante (bem acima de oscilações breves de um dígito) merece ser levado a quem controla o hypervisor. Em tipos de instância de nuvem com burst, créditos de CPU esgotados também podem aparecer como steal.
5. Em bare metal, %steal e st são estruturalmente zero, já que não existe hypervisor para reter CPU; uma leitura diferente de zero sugere que o sistema é, na verdade, um guest, ao contrário do que se supunha.
6. Se você também controla o hypervisor, correlacione com as métricas dele de CPU ready ou de espera do escalonador por VM, que confirmam, do outro lado, o que o guest só consegue inferir.

Resultado esperado

Uma separação clara entre "a aplicação usou toda a CPU que lhe foi dada" (steal baixo, us/sy altos) e "a aplicação não recebeu a CPU que pediu" (steal relevante e sustentado), o que muda o próximo passo de profiling de código para uma conversa sobre capacidade.

Limites e base de verificação

Os dois comandos são somente de leitura; não há nada para fazer backup nem para desfazer. Nenhuma das ferramentas consegue apontar o tenant responsável pela contenção. Algumas configurações de hypervisor (CPU pinning, núcleos dedicados) nunca produzem steal, mesmo sob carga, e alguns hypervisors nem sequer reportam steal ao guest, de modo que steal zero, por si só, não prova a ausência de contenção no lado do host. As definições citadas são as das próprias ferramentas, não um limiar universal de gravidade.