 |
| Bellacosa Mainframe apresenta caçando os vilões em zos performance tuning |
🍔💾 Essential z/OS Performance Tuning Workshop achando os vilões
Versão técnica: RMF, SMF e a arte de não tunar errado
O Essential z/OS Performance Tuning Workshop separa, logo de cara, dois tipos de profissionais:
-
Quem acha que faz performance tuning
-
Quem sabe onde olhar primeiro
Essa versão é para o segundo grupo — ou para quem quer migrar do 1️⃣ para o 2️⃣ sem trauma.
🎯 Regra zero do workshop
Nunca comece pelo parâmetro. Comece pela observação.
Antes de qualquer ALTER, DEFINE ou SET:
-
Qual workload?
-
Qual período?
-
O que mudou?
-
Existe baseline?
Sem isso, tuning vira superstição técnica.
🧠 CPU: o falso vilão
Onde olhar no RMF
RMF CPU Activity Report (Postprocessor)
Campos clássicos:
-
% Busy
-
% LPAR Utilization
-
% Logical Processor Dispatch
-
% IFA / zIIP / zAAP (quando aplicável)
Interpretação que o workshop ensina
-
CPU alta com response time estável → sistema saudável
-
CPU média com response time degradando → gargalo fora da CPU
-
CPU baixa + atraso → WLM ou I/O
📌 Easter egg técnico:
Se o LPAR Delay cresce, não é falta de tuning — é falta de peso ou política errada.
⚙️ WLM: tuning começa aqui, não no SYS1.PARMLIB
RMF Workload Activity Report
Campos críticos:
-
Service Class Period
-
Velocity
-
Average Response Time
-
Delay Reasons
Exemplo típico visto no workshop:
👉 Conclusão correta:
-
Não adianta subir prioridade
-
Não adianta mexer em CPU
-
O gargalo não é WLM, é dependência externa
💡 Lição central:
WLM não resolve gargalo físico. Ele apenas escolhe quem sofre primeiro.
📊 RMF Monitor III: o “agora dói aqui”
Uso correto (e erro comum)
Monitor III serve para:
-
Incidente ativo
-
Observação em tempo real
-
Confirmação de suspeita
Não serve para:
-
Análise histórica
-
Decisão estrutural
-
Justificativa pós-morte
Campos típicos:
-
Address Space Delay
-
Device Response Time
-
Enqueue Waits
📌 Erro clássico:
Usar Monitor III como prova definitiva em reunião de causa raiz.
🗃️ SMF: onde a discussão acaba
SMF 30 – Address Space Accounting
Usado para responder:
-
Quem consumiu CPU?
-
Quanto?
-
Em qual período?
Exemplo prático:
👉 Indício claro:
-
Espera externa
-
I/O
-
Lock
-
Dependência de outro job
SMF 70 / 72 – CPU e WLM
SMF 72 é o coração do tuning orientado a SLA.
Campos essenciais:
-
Service Class Performance Index
-
Delay Breakdown
-
Period Transitions
📌 Easter egg de workshop:
Performance Index < 1.0 não é vitória se o response time continua ruim.
SMF 74 – I/O e Storage
Onde muitos problemas se revelam.
Campos observados:
-
Device Response Time
-
Pending Time
-
Channel Utilization
Exemplo clássico:
-
CPU “sobrando”
-
Response time alto
-
3390 com Pending elevado
👉 Solução raramente é tuning de parâmetro.
Normalmente é layout, cache, storage tier ou concorrência mal planejada.
⚠️ Casos clássicos discutidos no workshop
🔥 “O batch atrasou tudo”
RMF mostra:
-
Batch em baixa prioridade
-
Online atrasando
SMF revela:
-
Batch segurando enqueue crítico
-
Online esperando lock
👉 Ajuste correto:
-
Revisar serialização
-
Reavaliar janela batch
-
Não subir prioridade às cegas
🔥 “Depois da mudança ficou lento”
Primeira pergunta ensinada no workshop:
Qual foi o último change?
Sem resposta clara:
-
tuning suspenso
-
investigação começa
📌 Lição dura:
Performance tuning não corrige change mal feito.
Ele só mascara — até piorar.
🚀 O que o workshop realmente forma
Não forma “tuner de parâmetro”.
Forma analista de comportamento do sistema.
Quem sai sabendo:
-
Correlacionar RMF + SMF
-
Defender decisão com dados
-
Evitar tuning destrutivo
-
Criar baseline útil
No CPD, isso vira reputação.
🧠 Frase final
“RMF mostra o sintoma.
SMF mostra a causa.
WLM executa a decisão — certa ou errada.”
O Essential z/OS Performance Tuning Workshop não ensina atalhos.
Ensina responsabilidade técnica em ambiente onde erro custa caro.
.png)
