 |
| Bellacosa Mainframe apresenta ferramenta de analise performance em z/os |
💥 VOCÊ NÃO TEM PROBLEMA DE CPU — VOCÊ TEM FALTA DE VISIBILIDADE
🔬 Sampling Tools no z/OS: O Raio-X que expõe o que seu COBOL está escondendo
Se você é dev COBOL sênior, já viveu isso:
“O batch está lento… deve ser DB2.”
“CPU alta… deve ser o código.”
“Está demorando… talvez seja I/O…”
💣 Spoiler: na maioria das vezes… está todo mundo errado.
E é aqui que entram os Sampling Performance Tools — as ferramentas que transformam achismo em evidência.
🧠 Origem — Por que sampling nasceu?
Nos primórdios do mainframe, performance era analisada com:
- Dumps
- Traces pesados
- Logs extensos
Problema?
❌ Alto overhead
❌ Impacto em produção
❌ Volume absurdo de dados
👉 A solução foi genial:
“E se observarmos o sistema em intervalos regulares… e usarmos estatística?”
Assim nasceram ferramentas como:
- Compuware Strobe
- IBM Application Performance Analyzer
- CA Mainframe Application Tuner
- Macro4 FreezeFrame
🔬 O conceito que muda tudo
📸 Sampling = tirar fotos da CPU
Imagine:
t1 → COBOL
t2 → DB2
t3 → VSAM
t4 → COBOL
Depois de milhares de amostras:
COBOL → 50%
DB2 → 30%
VSAM → 20%
💥 Pronto. Você tem a verdade.
💣 O maior erro de todo dev COBOL
“Vou otimizar meu código…”
Sem saber:
- onde está o problema
- quanto ele pesa
- se ele é realmente o culpado
👉 Isso é tuning no escuro.
🧠 O que o sampling realmente revela
✔ Módulo que consome CPU
✔ Offset (sim, linha lógica!)
✔ WAIT vs EXEC
✔ I/O vs DB2 vs ENQ
✔ System services (SVC, segurança, console)
🔥 Easter Egg (que poucos sabem)
🔍 Offset é praticamente um “GPS do bug”
Exemplo:
PROG001 offset X'1A' → 65% CPU
👉 Isso te leva direto para o trecho do COBOL
⚙️ Como usar na prática (passo a passo profissional)
1️⃣ Defina o alvo
- Job batch
- Step específico (sempre que possível)
2️⃣ Configure corretamente
👉 Regra de ouro:
Samples → 1000 a 1500 por minuto
Duração → 15 a 30 minutos
3️⃣ Use “Measure to Step End”
Especialmente para batch:
Nunca confie na duração média
4️⃣ Ative apenas coletores necessários
- DB2 → se houver SQL
- CICS → se for online
- MQ → se houver mensagens
💣 Ativar tudo = overhead inútil
5️⃣ Execute e aguarde
Nunca analise:
❌ sessão ativa
❌ poucos samples
6️⃣ Leia o relatório como um especialista
📊 Caso 1
EXEC 90%
WAIT 10%
👉 Problema = CPU (código)
📊 Caso 2
EXEC 30%
WAIT 70%
👉 Problema = recurso externo (VSAM, DB2, lock)
🔥 Caso real (estilo produção)
Sintoma
Batch de 2 horas
Sampling mostra
DB2 → 60%
COBOL → 25%
VSAM → 15%
Diagnóstico
👉 NÃO é COBOL
👉 É SQL
Ação
- Criar índice
- Ajustar WHERE
- Reduzir chamadas
Resultado
💥 2h → 20 min
🐢 VSAM — o vilão silencioso
Sampling revela coisas como:
- CI/CA splits
- excesso de I/O
- buffer ruim
💣 VSAM mal definido destrói performance sem aviso
🧠 DB2 — o assassino elegante
Um único SQL pode consumir mais CPU que todo o COBOL
Sampling mostra:
- tempo por SQL
- frequência
- impacto total
⚠️ Limitações (que você PRECISA entender)
❌ Não é trace
❌ Não mostra sequência exata
❌ Não mede rede (TCP/IP)
❌ Pode ignorar zIIP (em alguns casos)
🔥 Curiosidade (nível insider)
Sampling normalmente foca em CPU “cobrada” (GP)
Se você usa muito:
- zIIP
👉 Pode estar vendo só parte da história
💣 Erros clássicos em produção
❌ 100 samples/min → inútil
❌ duração longa (6h) → desperdício
❌ não usar step end → perde o problema
❌ ativar todos coletores → overhead
❌ otimizar COBOL sem olhar DB2
🧠 Modelo mental definitivo
Sampling responde:
→ Onde está o problema?
→ Quem está causando?
→ Por quê?
Você resolve:
→ Como corrigir
🔥 Frases pra guardar
“Sem sampling, você tem opinião.
Com sampling, você tem evidência.”
“CPU alta não é problema.
CPU mal usada é.”
“O gargalo não está no código…
está na forma como ele acessa dados.”
🚀 Conclusão
Sampling Tools não são só ferramentas.
São:
🧠 Um modelo mental
🎯 Um método de diagnóstico
💥 Um divisor entre júnior e especialista
💣 A verdade final
“Você não melhora performance olhando código…
você melhora entendendo comportamento.”
