 |
| Bellacosa Mainframe apresenta um checklist para analisar a performance e tuning em Mainframe |
💥 🧠 CHECKLIST PROFISSIONAL — SAMPLING PERFORMANCE TUNING
🎯 1. IDENTIFICAÇÃO DO PROBLEMA
Antes de sair rodando ferramenta:
✔ CPU alto?
✔ Elapsed alto?
✔ Batch lento?
✔ CICS lento?
💡 Pergunta chave
“É CPU ou WAIT?”
⚙️ 2. DEFINIÇÃO DO ALVO (TARGET)
Escolha corretamente:
- Job batch
- Região CICS
- Address space DB2
🔥 Regra de ouro
✔ Comece amplo (job)
✔ Refinar depois (step / programa)
🔬 3. DEFINIR O NÍVEL DE ANÁLISE
🔹 Macro (primeiro passo)
- Job inteiro
🔸 Micro (diagnóstico)
- Step específico
- Programa específico
💣 Erro comum
❌ Ir direto para detalhe sem contexto
⏱️ 4. CONFIGURAR DURAÇÃO
✔ 15–30 minutos padrão
✔ Batch curto → ajustar
💡 Regra
Duração suficiente para capturar comportamento real
🔢 5. CONFIGURAR SAMPLES
✔ 1000–1500 samples/min
📊 Referência
| Samples/min | Qualidade |
|---|---|
| < 500 | ruim |
| 1000 | bom |
| 1500+ | excelente |
💣 Erro crítico
❌ Poucos samples → diagnóstico errado
❌ Muitos → overhead desnecessário
🔁 6. ATIVAR “MEASURE TO STEP END”
✔ Sempre que possível
💡 Use quando:
- Batch imprevisível
- Jobs longos
- Problema intermitente
🔗 7. ATIVAR COLETORES CORRETOS
✔ DB2 → se houver SQL
✔ CICS → se for transação
✔ IMS → se aplicável
💣 Regra
Ative só o necessário
⚠️ Erro comum
❌ Ativar tudo → overhead alto
🚀 8. EXECUTAR A SESSÃO
✔ Monitorar status
✔ Aguardar finalizar
✔ Verificar número de samples
💣 Nunca faça
❌ Analisar sessão ativa
❌ Analisar com poucos samples
📊 9. VALIDAR QUALIDADE DO RELATÓRIO
Antes de confiar:
✔ Samples suficientes?
✔ Margem de erro baixa (<5%)?
✔ Duração adequada?
💡 Se não:
👉 Refaça a coleta
🔍 10. ANÁLISE PRINCIPAL (CPU vs WAIT)
📊 Interpretação
| Situação | Diagnóstico |
|---|---|
| CPU alto | problema de código |
| WAIT alto | problema externo |
🔥 11. IDENTIFICAR HOTSPOTS
Procurar:
- Módulo
- Offset
- Função
💡 Pergunta chave
“Quem está consumindo CPU de verdade?”
🧱 12. CLASSIFICAR O PROBLEMA
🔥 CPU-bound
- Loop
- Cálculo
- Algoritmo
🐢 WAIT-bound
- VSAM I/O
- DB2
- ENQ / lock
- MQ
🔬 13. DRILL-DOWN (INVESTIGAÇÃO)
Se CPU:
👉 Ir para código (COBOL / PL/I)
Se WAIT:
👉 Ir para:
- DB2 → SQL
- VSAM → dataset
- Sistema → ENQ
🛠️ 14. AÇÃO DE TUNING
🔥 CPU
✔ Reduzir loops
✔ Evitar processamento redundante
✔ Melhorar algoritmos
🐢 I/O
✔ Melhorar acesso VSAM
✔ Ajustar buffers
✔ Indexar DB2
🔐 LOCK
✔ Reduzir contenção
✔ Ajustar commit
🔁 15. VALIDAR RESULTADO
👉 Rodar nova sessão
Comparar:
- CPU antes/depois
- Tempo antes/depois
💣 Regra
Sem validação = tuning incompleto
📈 16. DOCUMENTAR
✔ Problema
✔ Diagnóstico
✔ Solução
✔ Ganho
💡 Isso vira:
- Base de conhecimento
- Aceleração futura
🔥 CHECKLIST RÁPIDO (versão bolso)
1. CPU ou WAIT?
2. Definir target
3. Configurar samples (1000/min)
4. Ativar step end
5. Executar sessão
6. Validar samples
7. Analisar CPU vs WAIT
8. Encontrar hotspot
9. Corrigir
10. Validar resultado
💣 ERROS QUE MATAM PERFORMANCE (e sua carreira 😅)
❌ Analisar sem dados suficientes
❌ Culpar DB2 sem prova
❌ Ignorar WAIT
❌ Não validar margem de erro
❌ Ajustar “no chute”
🧠 FRASE FINAL (nível arquiteto)
“Performance não se melhora com opinião.
Se melhora com evidência.”
Sem comentários:
Enviar um comentário