APRENDER. PRATICAR. EVOLUIR.Começar pela unidade e pela janela
Às 02:10, um batch está atrasado e o painel global parece normal. Antes de propor mais capacidade, regista qual processo executa o trabalho, a unidade, o cgroup e os seus ancestrais. Confirma cgroup v2, controladores disponíveis e versões locais. Guarda duas amostras com intervalo monotónico e identidade da instância. Neste exercício, os workers usam fair-class e não existe burst. Um nome de path pode ser reutilizado após restart; isso não torna comparáveis os contadores das duas instâncias. O objetivo inicial é formular uma hipótese que possa ser testada com uma mudança limitada.
Um orçamento partilhado pelos workers
CPUQuota=50% corresponde a um teto relativo a uma CPU, mesmo num host de oito CPUs. Com cpu.max=50000 100000, quatro workers que acumulam 12 500 µs cada consomem 50 000 µs no modelo. Paralelismo pode gastar o orçamento mais cedo; não o multiplica. Não derives daqui uma pausa exata ou ganho linear de throughput: scheduler, carga e outros limites influenciam o resultado. CPUWeight organiza competição e AllowedCPUs limita onde executar. Nenhum destes nomes deve ser usado como sinónimo de quota ou reserva garantida.
Inspecionar o ancestral que limita
Um filho em max pode partilhar uma slice pai com quota finita. Se dois batches concorrem nessa slice, alterar apenas o filho pode não resolver o atraso. Observa os irmãos e o pai; liga cada contador ao âmbito que documenta. No exemplo, nr_periods cresce 100 e nr_throttled cresce 30. Isso significa 30 períodos adicionais com throttling entre 100 observados, não 30 segundos perdidos nem 30% dos pedidos falhados. O handover deve incluir a latência e o backlog para ligar a evidência técnica ao impacto.
Memória: distinguir pressão, limite e morte
Um serviço pode ficar muito lento sem perder processos. Se MemoryHigh foi reduzido e high começa a crescer, investiga reclaim, pressão e carga antes de diagnosticar fuga. MemoryMax é uma contenção diferente: quando a utilização não pode ser reduzida no limite, pode ocorrer OOM no grupo. A simples leitura de oom_kill não identifica a origem: esse contador inclui processos do grupo mortos por diferentes tipos de OOM killer. Cruza logs, vítimas, limites locais e ancestrais. RAM livre no host e estado active não substituem esta análise.
Não atribuir um evento agregado à unidade errada
No cenário normal sem memory_localevents, memory.events de uma slice agrega descendentes; memory.events.local delimita eventos locais. Se o agregado aumenta e o local não, investiga os filhos. Regista as opções de montagem, pois podem alterar a leitura esperada. Uma alteração no contador aponta um evento na janela; não fornece automaticamente nome da vítima ou causa raiz. Evita um relatório que acusa o serviço de pagamentos apenas porque o seu nome aparece na slice que também contém um processo de relatórios.
PSI mede tempo de bloqueio
Usa memory.pressure para separar pressão de ocupação. some observa períodos com pelo menos alguma tarefa bloqueada; full observa quando todas as tarefas não ociosas desse âmbito estão bloqueadas simultaneamente. Full é subconjunto de some: não somes os dois para obter pressão total. Se some total cresce 1 500 000 µs em 10 000 000 µs, o intervalo mostra 15%. Um incremento full de 400 000 µs na mesma janela corresponde a 4%, incluídos nos 15%. Estes cálculos não são percentagem de RAM nem um percentil de latência. Compara com pedidos, throughput e carga.
Uma experiência operacional limitada
Para o batch, compara uma janela com carga equivalente, preservando contadores e resultado inicial. A equipa pode desfasar jobs, reduzir concorrência ou ajustar temporariamente a quota no nível autorizado. Para memória, uma reversão do limiar recentemente alterado pode ser mais delimitada do que aumentar todos os tetos. Define previamente duração, responsável, condições de reversão e critérios: conclusão antes do cut-off, reconciliação, erro e latência dos vizinhos. Melhorar só o indicador que motivou a intervenção não basta se o trabalho fica incompleto.
Exercício guiado e passagem de turno
No fixture abaixo, calcula a quota equivalente, a fração de períodos com throttling e as duas frações PSI. Respostas: 0,5 CPU, 30%, 15% some e 4% full. Depois considera que a unidade é recriada: começa uma nova baseline, sem transformar um contador menor numa melhoria. Entrega ao turno seguinte identidade, janela, configuração própria e ancestral, hipótese, decisão autorizada e resultado de negócio. Os cálculos locais verificam apenas estes dados fictícios. O percurso requer prática separada num Linux autorizado para observar scheduler, memória e distribuição reais.
Synthetic fixture; cgroup v2; fair-class; no burst
cpu.max: 50000 100000
instance: batch-A (unchanged)
interval_usec: 10000000
nr_periods: 1000 -> 1100
nr_throttled: 40 -> 70
memory.pressure some total: 2000000 -> 3500000
memory.pressure full total: 100000 -> 500000Uma slice com quota partilhada atrasa dois batches apesar de CPU livre. O pai, os irmãos e a janela de negócio fazem parte do diagnóstico.
Armadilhas comuns
Quota como reserva; peso como teto; high como morte; eventos agregados como locais; somar some/full; calcular deltas entre instâncias.
Tópicos relacionados: Diagnóstico de recursos · Gestão de mudanças
Identifica âmbito e janela, testa uma hipótese limitada e valida o resultado do serviço.
Referência: Control Group v2 · XK0-006 V8