 |
| Bellacosa Mainframe apresenta o zBNA analise de processos batch |
☕ Um Café no Bellacosa Mainframe
🎧 zBNA — A Conversação do Batch: Harry Caul e o Mistério do Critical Path
Sob a batuta de Harry Caul, de The Conversation: no mainframe, assim como numa gravação de vigilância, o problema raramente está simplesmente no sinal mais alto. Está naquilo que acontece entre os sinais — nas pausas, dependências, esperas e detalhes que ninguém percebeu.
Imagine uma sala silenciosa.
Na parede existem gráficos de CPU, relatórios de utilização, tempos de execução, estatísticas de I/O e algumas planilhas de capacity planning.
O batch deveria ter terminado às 03:00.
São 03:17.
Alguém olha para o gráfico e diz:
— Precisamos de um mainframe maior.
No fundo da sala, Harry Caul não responde.
Ele coloca os fones de ouvido.
Volta a fita.
Escuta novamente.
Porque Harry aprendeu uma coisa durante toda uma vida ouvindo conversas que outras pessoas não deveriam ouvir:
uma informação isolada pode dizer algo completamente diferente quando colocada no contexto correto.
E é exatamente esse o problema que encontramos quando tentamos fazer sizing de um ambiente IBM Z olhando somente para capacidade de processador.
Bem-vindo à investigação.
🎧 1. Harry Caul não começaria olhando o processador
Para quem nunca assistiu a The Conversation, Harry Caul é um especialista em vigilância e gravação de áudio.
Seu trabalho não consiste simplesmente em gravar sons.
Ele precisa separar ruído de informação.
Uma conversa aparentemente banal pode esconder algo importante.
Uma frase pode assumir outro significado quando escutada novamente.
No nosso datacenter acontece algo parecido.
Temos:
CPU utilization
MSU
MIPS
Elapsed Time
CPU Time
I/O
Wait
ENQ
Db2
VSAM
JES2
WLM
Scheduler
Tudo está falando ao mesmo tempo.
O erro seria escolher o gráfico mais chamativo e concluir:
CPU alta
↓
Falta capacidade
↓
Comprar processador
Pode ser verdade.
Mas ainda não sabemos.
Harry Caul provavelmente perguntaria:
“O que aconteceu antes disso?”
Essa pergunta nos leva ao IBM Z Batch Network Analyzer — zBNA.
🕸️ 2. O batch é uma conversa entre JOBs
Para um programador COBOL iniciante, uma sequência batch pode parecer algo relativamente simples.
Temos JOBs:
JOB001
JOB002
JOB003
JOB004
JOB005
Parece uma lista.
Mas operacionalmente eles podem estar relacionados:
+--> JOB B --+
| |
JOB A -------+ +--> JOB D --> JOB E --> FIM
| |
+--> JOB C --+
Agora a história mudou.
JOB B e JOB C dependem de A.
JOB D depende de alguma condição relacionada aos anteriores.
JOB E depende de D.
Portanto, não estamos mais observando apenas programas.
Estamos observando uma rede de dependências.
É quase uma conversação:
JOB A: terminei.
JOB B: agora posso começar.
JOB C: eu também.
JOB C: terminei.
JOB D: ainda não.
JOB B: terminei.
JOB D: agora sim.
JOB D: processando...
JOB D: processando...
JOB D: processando...
JOB E: esperando...
Harry Caul imediatamente prestaria atenção naquele silêncio.
Por que JOB E está esperando?
⏱️ 3. O silêncio também faz parte da gravação
Esse é um conceito fundamental para quem começa a estudar performance.
Um programa pode estar demorando sem estar usando CPU.
Considere:
Elapsed Time = 42 minutos
CPU Time = 11 minutos
Onde estão os outros 31 minutos?
Essa é uma pergunta maravilhosa.
Porque começamos a procurar:
I/O WAIT
LOCK
ENQ
DATASET CONTENTION
DB2 LOCKING
QUEUE
SCHEDULING
RESOURCE WAIT
NETWORK
APPLICATION SERIALIZATION
Imagine nossa investigação encontrando:
Elapsed Time 42 min
├── CPU 11 min
├── I/O 17 min
├── Lock/ENQ 8 min
└── Outros waits 6 min
Agora tente resolver isso simplesmente colocando mais processador.
Talvez os 11 minutos de CPU melhorem.
Mas e os outros?
Essa é a primeira grande lição:
Elapsed Time não é simplesmente CPU Time usando outro relógio.
🐉 4. Encontramos JOB D
Voltemos à cadeia:
JOB A = 12 min
+-- JOB B = 18 min --+
| |
+-- JOB C = 7 min --+
|
JOB D = 42 min
|
JOB E = 9 min
B e C podem executar simultaneamente.
Portanto não podemos simplesmente fazer:
12 + 18 + 7 + 42 + 9
Precisamos considerar a dependência.
Nesse exemplo simplificado:
12 + MAX(18,7) + 42 + 9
Temos:
12 + 18 + 42 + 9 = 81 minutos
E observe JOB D:
42 / 81 ≈ 52%
Ele ocupa mais da metade do caminho.
Harry Caul colocaria os fones novamente.
Por que exatamente são 42 minutos?
Essa pergunta vale potencialmente muito dinheiro.
🛣️ 5. Critical Path — quem realmente possui o relógio?
Chegamos ao conceito central:
Critical Path.
Imagine uma rede maior:
JOB B --------+
/ \
JOB A ---------- +---- JOB F ----+
\ / |
JOB C --> JOB D +--> JOB H
/
JOB E -------------------------+
Podemos possuir diferentes caminhos:
A → B → F → H
A → C → D → F → H
E → H
Um deles determinará quando todo o processo poderá terminar.
Esse é nosso caminho crítico.
E aqui surge uma descoberta extremamente importante:
O JOB que mais consome CPU não precisa ser o JOB mais importante para reduzir a janela batch.
Suponha que JOB X consuma enorme quantidade de CPU.
Todo mundo olha para ele.
JOB X
CPU TIME = █████████████████████
Parece culpado.
Mas JOB X possui bastante folga e está fora do critical path.
Você consegue uma otimização fantástica:
JOB X
-30% elapsed
Resultado sobre o fechamento:
0 minutos
Nada.
O batch termina exatamente no mesmo horário.
Enquanto isso, um JOB pequeno pertencente ao critical path perde cinco minutos esperando determinado recurso.
Eliminar aquela espera poderia antecipar o fechamento em aproximadamente cinco minutos.
Harry Caul diria:
vocês estavam ouvindo a pessoa errada.
💻 6. Programador COBOL: não condene o programa imediatamente
Encontramos JOB D.
A primeira reação pode ser:
— COBOL velho!
Calma.
Talvez o programa esteja perfeitamente correto.
Imagine:
PERFORM PROCESSA-REGISTRO
UNTIL EOF.
O programa está executando adequadamente.
Mas cada ciclo depende de acesso a um recurso.
Pode existir:
COBOL
↓
VSAM
↓
Dataset
↓
ENQ
↓
WAIT
Ou:
COBOL
↓
SQL
↓
Db2
↓
LOCK
↓
WAIT
Ou ainda:
JOB
↓
Scheduler
↓
Dependency
↓
WAIT
Nenhuma quantidade de indignação contra o COBOL resolverá automaticamente isso.
E talvez nenhuma quantidade adicional de CPU resolva.
Precisamos encontrar a causa.
⚙️ 7. Capacity não é a mesma coisa que velocidade
Aqui encontramos outra armadilha.
Imagine dois sistemas hipotéticos:
SYSTEM A
10 engines × velocidade X
SYSTEM B
6 engines × velocidade Y
Mesmo que determinada medida agregada de capacidade pareça semelhante, o comportamento do workload pode ser diferente.
Por quê?
Imagine trabalho altamente paralelo:
JOB1 ──┐
JOB2 ──┤
JOB3 ──┼──> resultado
JOB4 ──┤
JOB5 ──┘
Vários engines podem ser aproveitados.
Agora imagine:
JOB1
↓
JOB2
↓
JOB3
↓
JOB4
Colocar dezenas de engines disponíveis ao lado dessa sequência não faz os JOBs executarem simultaneamente por mágica.
Temos então que distinguir:
aggregate capacity
de
per-engine performance
e ambos de:
usable parallelism.
🧵 8. Usable parallelism — dez microfones não criam dez conversas
Harry Caul poderia instalar dez microfones.
Mas se existe apenas uma pessoa falando, continuamos tendo uma conversa.
No mainframe podemos possuir:
10 engines disponíveis
enquanto o workload oferece:
1 unidade relevante de trabalho executável
Visualmente:
CPU0 ████████████
CPU1 ░░░░░░░░░░░░
CPU2 ░░░░░░░░░░░░
CPU3 ░░░░░░░░░░░░
CPU4 ░░░░░░░░░░░░
Adicionar CPU5, CPU6 e CPU7 não necessariamente ajudará.
Talvez precisemos investigar:
dependências;
scheduler;
initiators;
particionamento;
desenho dos JOBs;
datasets;
banco;
I/O;
serialização da aplicação.
Esse é o significado prático de usable parallelism.
Não importa somente quanta capacidade existe.
Importa quanto daquele paralelismo o workload consegue realmente consumir.
🏭 9. JES2, WLM e scheduler entram na sala
Agora nossa investigação fica mais interessante.
Eu dividiria o problema em quatro níveis:
BUSINESS PROCESS
↓
BATCH NETWORK
↓
z/OS RESOURCE BEHAVIOR
↓
PROCESSOR
No terceiro andar dessa investigação encontramos:
JES2
WLM
Initiators
Scheduler
I/O
Db2
VSAM
ENQ
Storage
Memory
Network
Imagine comprarmos um IBM Z muito mais poderoso.
Temos:
PROCESSOR
████████████████████████
JOB
██████
WAIT
████████████████████████████████
O processador está disponível.
O JOB não está trabalhando.
Harry Caul aumenta o volume.
Nada.
Porque o problema não está onde todos estavam olhando.
🎧 10. CPU a 95%: culpada!
Não tão rápido.
Encontramos:
CPU = 95%
Parece assustador.
Mas existe trabalho útil sendo processado?
O SLA está sendo atendido?
Existe fila significativa esperando CPU?
A utilização é sustentada ou apenas um pico?
O comportamento está dentro do esperado?
Então 95% isoladamente não constitui diagnóstico.
Agora encontramos:
CPU = 40%
Maravilha!
Temos sobra.
Talvez.
Ou talvez metade do workload esteja esperando recursos.
Portanto:
CPU HIGH ≠ automaticamente ruim
CPU LOW ≠ automaticamente bom
Um gráfico é uma pista.
Não é uma sentença.
🕵️ 11. War Room Mainframe sob a batuta de Harry Caul
Agora apagamos as luzes.
Colocamos JOB D no centro da tela.
Pergunta número um:
Por que exatamente são 42 minutos?
Não:
Quanto CPU ele usa?
Ainda não.
Primeiro:
42 MINUTOS
|
+-- CPU?
|
+-- I/O?
|
+-- ENQ?
|
+-- Db2 lock?
|
+-- VSAM?
|
+-- Queue?
|
+-- Scheduler?
|
+-- Dependency?
|
+-- Application serialization?
Então começamos a correlacionar evidências.
Esse é o ponto em que capacity planning deixa de ser comparação de catálogo e começa a se aproximar de investigação.
🔄 12. Harry Caul volta a fita
Encontramos o gargalo.
PATH A:
81 minutos
PATH B:
75 minutos
Otimizamos PATH A:
81 → 70
Excelente!
Acabou?
Não.
Agora temos:
PATH A = 70
PATH B = 75
PATH B tornou-se o novo critical path.
O gargalo mudou de endereço.
Esse comportamento ensina uma das coisas mais importantes sobre performance:
MEASURE
↓
ANALYZE
↓
FIND CRITICAL PATH
↓
OPTIMIZE
↓
MEASURE AGAIN
↓
RECALCULATE
↺
Harry Caul volta a gravação porque uma segunda audição pode revelar algo que a primeira interpretação escondeu.
Nós fazemos a mesma coisa.
Depois de modificar o workload, medimos novamente.
💰 13. Performance também conversa com dinheiro
Existe outro microfone naquela sala.
Custo.
Sizing não deveria ser simplesmente:
Qual máquina é mais rápida?
Precisamos equilibrar:
PERFORMANCE
+
CAPACITY
+
SLA
+
SOFTWARE COST
+
OPERATIONAL RISK
+
GROWTH
Porque uma solução tecnicamente elegante pode não ser economicamente interessante.
Da mesma maneira, economizar dinheiro sacrificando um SLA crítico pode custar muito mais ao negócio.
Sizing é um problema de engenharia.
Mas também é um problema de negócio.
🎯 14. Antes do zBNA existe uma pergunta zero
Eu acrescentaria uma etapa antes de qualquer análise:
Qual é o SLA?
Imagine que o fechamento termina às 04:30.
Caso A:
SLA = 06:00
Fim = 04:30
Temos determinada situação.
Caso B:
SLA = 03:00
Fim = 04:30
Agora temos um incidente.
Os mesmos JOBs.
A mesma CPU.
O mesmo hardware.
O mesmo elapsed.
Contextos de negócio completamente diferentes.
Performance sem objetivo é apenas uma coleção muito bonita de gráficos.
🧠 15. As seis perguntas de Harry Caul
Se eu estivesse ensinando isso para um programador COBOL iniciante, colocaria seis perguntas ao lado do terminal:
1. Quando o negócio precisa terminar?
SLA.
2. O que precisa acontecer para ele terminar?
Batch Network.
3. Qual sequência determina esse horário?
Critical Path.
4. Por que os componentes críticos estão demorando?
CPU, I/O, locks, ENQ, Db2, VSAM, scheduling, dependências.
5. O workload consegue utilizar capacidade adicional?
Usable Parallelism.
6. Qual alteração entrega maior benefício considerando custo e risco?
Sizing.
Somente então colocamos os candidatos a processador sobre a mesa.
☕ 16. A tradução para quem está começando no COBOL
Você escreveu:
PERFORM PROCESSO-A
PERFORM PROCESSO-B
PERFORM PROCESSO-C
PERFORM PROCESSO-D
Alguém aparece oferecendo um computador duas vezes mais rápido.
Parece razoável imaginar:
2 × PERFORMANCE
=
1/2 ELAPSED TIME
Mas descobrimos:
PROCESSO-A → CPU
PROCESSO-B → espera arquivo
PROCESSO-C → espera outro JOB
PROCESSO-D → espera lock Db2
Ops.
Nosso computador duas vezes mais rápido não pode acelerar magicamente aquilo que não está usando processador.
Quando ampliamos isso para centenas ou milhares de JOBs, datasets, bancos, schedulers, dependências e recursos compartilhados, começamos a compreender por que precisamos enxergar o workload como sistema.
É aí que o zBNA se torna particularmente interessante.
🥚 Easter Egg — 03:17
O processamento deveria terminar às 03:00.
Harry está sentado no fundo da War Room.
03:00
Nada.
03:05
Nada.
03:11
Os gerentes começam a olhar para o dashboard.
03:16
Alguém diz:
— Precisamos de mais CPU.
Harry coloca os fones.
03:17
Ele volta alguns minutos da gravação operacional.
Na tela:
JOB D
STATUS: WAIT
CPU?
AVAILABLE
Ele continua seguindo a cadeia.
Predecessor.
Dataset.
ENQ.
Wait.
Silêncio.
Harry tira lentamente os fones.
Não faltava processador.
Faltava ouvir a conversa inteira.
🏁 Conclusão — o mainframe também deixa pistas
O ensinamento mais importante do zBNA não é simplesmente aprender a utilizar outra ferramenta.
É aprender a fazer uma pergunta melhor.
Um problema de performance não significa automaticamente:
NEED MORE CAPACITY
A janela batch é resultado de uma combinação muito mais interessante:
BATCH WINDOW
=
CPU
+
DEPENDENCIES
+
SERIALIZATION
+
PARALLELISM
+
I/O
+
CONTENTION
+
SCHEDULING
+
RESOURCE AVAILABILITY
+
APPLICATION BEHAVIOR
O processador está dentro dessa equação.
Às vezes ele será justamente o gargalo e aumentar capacidade será a decisão correta.
Mas precisamos demonstrar isso.
Harry Caul não condenaria alguém porque uma palavra pareceu suspeita na primeira reprodução.
Ele limparia o ruído.
Voltaria a fita.
Compararia os sinais.
Procuraria o contexto.
No capacity planning deveríamos ter a mesma disciplina.
Antes de perguntar:
“Qual IBM Z devemos comprar?”
pergunte:
“Quem está segurando o batch?”
Depois encontre o critical path.
Descubra quanto do elapsed realmente depende de CPU.
Investigue I/O, locks, datasets, scheduler, JES2, WLM, Db2, VSAM, ENQ e dependências.
Descubra quanto paralelismo é realmente utilizável.
Meça.
Simule.
Altere.
Meça novamente.
E somente depois faça sizing.
Porque existe uma diferença enorme entre possuir uma gravação e compreender a conversa.
Da mesma maneira, existe uma diferença enorme entre possuir métricas e compreender o workload.
🎧 Não faça sizing do mainframe antes de fazer sizing do problema.
O processador pode fornecer a potência.
Mas é o critical path que possui o relógio.
E, às 03:17, quando todos estiverem olhando para a CPU, talvez o verdadeiro gargalo esteja silenciosamente esperando em algum lugar da conversação.
