 |
| Bellacosa Mainframe e a engenharia de performance no mainframe |
☕ Um Café no Bellacosa Mainframe
Engenharia de Performance em Mainframe sem Mistérios
Quando um Programador COBOL Embarca no Seaview e Descobre que CPU Alta é Apenas o Primeiro Sinal no Sonar
O painel do submarino começa a piscar.
Uma luz amarela acende na sala de controle.
Depois outra.
No sonar, um objeto gigantesco se aproxima lentamente pelo lado de boreste.
O Capitão pergunta:
— É uma criatura marinha?
O operador responde:
— Negativo, senhor. Parece uma fila de I/O crescendo no volume de produção.
O Almirante observa os instrumentos, ajusta os óculos e diz:
— Então chamem o engenheiro de performance. E tragam café.
Bem-vindo à Engenharia de Performance em Mainframe, uma disciplina em que números aparentemente inocentes podem esconder problemas capazes de afetar milhões de transações, atrasar processamento batch, aumentar custos de software e transformar uma madrugada tranquila em uma expedição ao fundo do oceano.
Para um programador COBOL iniciante, performance pode parecer assunto exclusivo de sysprog, especialista de capacidade ou administrador de sistemas. Mas isso é um erro.
Seu programa consome CPU.
Seu programa faz I/O.
Seu programa acessa Db2, VSAM, IMS, MQ e CICS.
Seu programa pode gerar contenção, espera, filas, locks, page-ins, excesso de logging, leitura desnecessária e milhões de instruções que ninguém percebeu durante os testes.
Portanto, entender Engenharia de Performance não é abandonar o COBOL.
É aprender a enxergar o mundo que existe abaixo de cada READ, cada WRITE, cada EXEC CICS, cada SELECT e cada CALL.
1. O que é Engenharia de Performance?
Engenharia de Performance é o conjunto de práticas usadas para medir, analisar, prever, otimizar e controlar o comportamento de sistemas computacionais.
No mainframe, ela procura responder perguntas como:
O sistema está entregando o tempo de resposta esperado?
Existe capacidade suficiente para o crescimento?
Qual workload está consumindo mais recursos?
O problema está na aplicação, no sistema operacional, no banco, no storage ou na rede?
A utilização atual é normal?
Existe uma tendência de saturação?
Quanto custa essa ineficiência?
O ambiente sobreviverá ao próximo fechamento mensal?
O novo release aumentou CPU?
O zIIP está sendo bem utilizado?
O WLM está protegendo as aplicações críticas?
Engenharia de Performance não é simplesmente olhar um gráfico de CPU.
É entender a relação entre:
carga + recursos + prioridade + arquitetura + tempo + custo + impacto no negócio.
No Seaview, não basta saber a profundidade.
É necessário saber a pressão do casco, a velocidade, o combustível, a direção da corrente, a temperatura da água e a distância até o próximo porto.
No IBM Z acontece exatamente o mesmo.
2. Performance não é velocidade
Muita gente usa “performance” como sinônimo de rapidez.
Mas performance é mais ampla.
Um sistema pode ser rápido e mesmo assim ser ineficiente.
Imagine um programa COBOL que termina em dois minutos, mas consome uma quantidade absurda de CPU. Talvez ele pareça rápido porque o mainframe possui muita capacidade disponível. Porém, quando centenas de programas semelhantes executarem ao mesmo tempo, o problema aparecerá.
Da mesma forma, um sistema pode ter baixa CPU e apresentar péssimo tempo de resposta porque está esperando por:
I/O;
locks;
ENQ;
storage;
rede;
fila MQ;
Db2;
VSAM;
tape;
outro address space;
tarefa serializada;
serviço externo.
A primeira grande lição é esta:
CPU alta não significa necessariamente problema, e CPU baixa não significa necessariamente saúde.
3. As principais atividades do engenheiro de performance
O profissional de performance atua em várias frentes.
Monitoramento
Ele acompanha o ambiente continuamente.
Observa:
consumo de GCP;
consumo de zIIP;
utilização de LPAR;
peso de partição;
dispatch time;
paging;
I/O;
response time;
filas;
WLM;
service classes;
storage;
CICS;
Db2;
IMS;
MQ;
batch;
redes;
Coupling Facility.
O objetivo é perceber desvios antes que o usuário perceba.
Análise de incidentes
Quando ocorre lentidão, timeout, abend em massa, filas ou degradação, o especialista procura a causa.
Ele pergunta:
Quando começou?
O que mudou?
Quais sistemas foram afetados?
Foi geral ou localizado?
O problema é recorrente?
Existe correlação com deploy, batch, fechamento ou pico de usuários?
Houve alteração de configuração?
Algum recurso ficou saturado?
Planejamento de capacidade
Aqui o foco deixa de ser apenas “o que está acontecendo?” e passa a ser:
“O que acontecerá daqui a três, seis ou doze meses?”
O especialista analisa crescimento, sazonalidade, novas aplicações, migrações, aquisições e projeções de negócio.
Otimização de custos
No mainframe, performance e custo caminham juntos.
Um programa que utiliza CPU demais pode aumentar o custo de software.
Uma consulta Db2 mal desenhada pode consumir milhões de instruções desnecessárias.
Um workload que poderia usar zIIP pode acabar executando em GCP.
Um fechamento mal planejado pode elevar o pico mensal de consumo.
O engenheiro de performance não procura apenas velocidade.
Procura eficiência econômica.
Avaliação de mudanças
Antes e depois de uma mudança, ele compara resultados.
Exemplos:
4. O dia a dia de um especialista
A rotina varia conforme a empresa, mas geralmente começa pela observação da saúde do ambiente.
Imagine o engenheiro chegando à sala de controle do Seaview.
Ele não começa desmontando o motor.
Primeiro, olha os instrumentos.
Pela manhã
Normalmente verifica:
incidentes da madrugada;
jobs que atrasaram;
batch critical path;
picos de CPU;
uso de zIIP;
filas de I/O;
tempo de resposta CICS;
threads Db2;
locks e deadlocks;
filas MQ;
paging;
alertas de storage;
goals perdidos pelo WLM.
Também compara com o comportamento esperado.
Se o fechamento mensal sempre eleva a CPU, isso pode ser normal.
Se uma terça-feira comum apresenta o mesmo pico de um fechamento, algo precisa ser investigado.
Durante o dia
O especialista participa de reuniões com:
aplicações;
infraestrutura;
banco de dados;
storage;
redes;
capacity planning;
gestão;
arquitetura;
fornecedores.
Ele traduz linguagem técnica para impacto de negócio.
Não basta dizer:
“houve aumento de 22% no dispatch time”.
É necessário explicar:
“o aumento ocorreu no período de maior volume, afetou o tempo de resposta do serviço de pagamentos e pode comprometer o SLA caso o crescimento continue”.
No final do dia
Pode gerar relatórios, registrar conclusões, revisar mudanças e atualizar previsões.
Uma análise que não é documentada tende a ser esquecida.
E um problema esquecido costuma voltar.
5. Principais fontes de dados
O mainframe é provavelmente uma das plataformas mais instrumentadas da história da computação.
Ele gera telemetria detalhada há décadas.
SMF
O System Management Facility é o grande diário de bordo do z/OS.
Registra uma enorme variedade de eventos e medições.
Há registros para:
Para o engenheiro de performance, SMF é ouro.
Sem dados históricos, muitas conclusões viram opinião.
RMF
O Resource Measurement Facility ajuda a medir recursos do sistema.
Ele oferece informações sobre:
O RMF é como o conjunto de sensores da sala de máquinas.
Monitor III
Permite observar comportamento mais próximo do tempo real.
É muito útil durante incidentes.
Você pode investigar quem está esperando, qual workload está atrasado e onde existe contenção.
Dados das subsistemas
CICS, Db2, IMS, MQ, storage e redes também possuem seus próprios monitores e registros.
É por isso que performance exige visão integrada.
Um problema no CICS pode ter origem no Db2.
Um problema no Db2 pode ter origem no storage.
Um problema no storage pode refletir em timeouts na aplicação.
Tudo está conectado.
6. Principais ferramentas
Cada empresa utiliza um conjunto diferente, mas algumas categorias aparecem com frequência.
IBM RMF e SMF
São a base da análise de performance no z/OS.
IBM OMEGAMON
Muito usado para monitoramento de:
z/OS;
CICS;
Db2;
IMS;
MQ;
storage;
redes.
Ajuda a visualizar métricas, alertas e problemas em tempo próximo do real.
IntelliMagic Vision for IBM Z
Transforma grandes volumes de dados operacionais em análises visuais, correlações, Health Insights, tendências e detecção de mudanças.
Sua força está em reunir dados de diversas áreas e aplicar conhecimento especializado.
IBM Z Performance and Capacity Analytics
Ajuda na análise histórica, relatórios e planejamento.
BMC AMI
Possui soluções para monitoramento, automação, performance e gestão operacional.
Broadcom Mainframe Software
Inclui ferramentas de monitoramento, performance, automação e capacity management.
SDSF
Embora não seja uma plataforma completa de performance, o SDSF é fundamental para analisar jobs, address spaces, utilização e situações operacionais.
Db2 Performance Expert e monitores Db2
Essenciais para investigar:
SQL;
threads;
locks;
buffer pools;
getpages;
I/O;
accounting;
statistics.
CICS Performance Analyzer
Ajuda a entender transações CICS, tempo de resposta, CPU, waits e comportamento das tarefas.
7. O que analisar em CPU
CPU é importante, mas deve ser analisada com contexto.
GCP
Os General Purpose Processors executam a maior parte do trabalho tradicional.
O especialista observa:
zIIP
O zIIP executa workloads elegíveis, como partes de Db2, Java, XML, criptografia e outros componentes.
É importante analisar:
quanto trabalho é elegível;
quanto está realmente executando no zIIP;
quanto está transbordando para GCP;
se existe capacidade suficiente de zIIP;
se aplicações poderiam aproveitar mais esse recurso.
Um ambiente com zIIP saturado pode enviar trabalho elegível para processadores gerais, aumentando custos.
Dispatch Time
É o tempo em que uma unidade de trabalho realmente executa em processador.
Se o workload está pronto, mas não recebe CPU, pode haver atraso de dispatch.
LPAR Busy e CPC Busy
Uma LPAR pode estar muito ocupada enquanto o CPC ainda possui capacidade.
Ou o CPC inteiro pode estar perto do limite.
São situações diferentes.
8. O que analisar em memória
No z/OS, memória insuficiente pode gerar paging.
Paging significa que páginas de memória precisam ser movidas entre armazenamento central e auxiliar.
Algum paging pode ser normal.
Paging excessivo é como obrigar a tripulação do Seaview a buscar cada ferramenta em um depósito localizado três compartimentos abaixo.
O especialista observa:
Em CICS, também é necessário observar áreas como DSAs.
Em Db2, buffer pools são fundamentais.
9. O que analisar em I/O
I/O é uma das áreas mais importantes.
Um programa pode estar usando pouca CPU porque passa quase todo o tempo esperando dados.
Métricas comuns incluem:
I/O rate;
response time;
connect time;
disconnect time;
pending time;
IOSQ time;
cache hit;
quantidade de operações;
concentração por volume;
concentração por device;
throughput.
IOSQ
Representa espera na fila do subsistema de I/O.
Se muitos pedidos aguardam para usar o mesmo recurso, IOSQ pode crescer.
Pending Time
Pode indicar espera antes que a operação seja atendida.
Connect Time
É o tempo de transferência efetiva.
Disconnect Time
Pode envolver períodos em que o dispositivo não está conectado ao canal durante a operação.
A relação entre esses tempos ajuda a descobrir onde está o atraso.
10. O que analisar em CICS
No CICS, o especialista verifica:
response time;
dispatch time;
suspend time;
CPU por transação;
quantidade de tasks;
MXT;
storage;
waits;
file control;
Db2 calls;
MQ calls;
temporary storage;
transient data;
program loads;
abends;
transaction rate.
Um tempo de resposta alto pode ser dividido em partes.
Talvez a transação tenha executado apenas 20 milissegundos de CPU, mas esperado dois segundos por Db2.
Logo, otimizar o COBOL pode não resolver.
É necessário identificar onde a transação ficou suspensa.
11. O que analisar em Db2
Db2 merece uma expedição própria.
Os principais pontos incluem:
Uma instrução SQL aparentemente simples pode provocar milhões de getpages.
Um índice ausente pode transformar uma busca seletiva em varredura completa.
Um commit mal posicionado pode causar logging excessivo.
Dica Bellacosa
Nunca otimize SQL olhando apenas o texto.
Olhe também:
access path;
cardinalidade;
estatísticas;
frequência;
volume;
custo acumulado.
Um SQL que custa pouco, mas executa 10 milhões de vezes, pode ser mais importante que um SQL caro executado uma vez.
12. O que analisar em VSAM
Em VSAM, observe:
Um KSDS com muitos splits pode sofrer degradação progressiva.
Um programa que faz leituras aleatórias em massa pode gerar enorme I/O.
Uma chave mal distribuída pode concentrar atividade.
13. Solução de problemas passo a passo
Quando chega a mensagem clássica:
“O sistema está lento.”
Não comece alterando parâmetros.
Comece investigando.
Passo 1 — Defina o problema
“Lento” significa o quê?
tela demorando?
batch atrasando?
timeout?
CPU alta?
fila crescendo?
relatório demorando?
apenas um usuário?
todos os usuários?
Sem delimitar o problema, você investiga o oceano inteiro.
Passo 2 — Descubra quando começou
Determine:
Passo 3 — Identifique o escopo
Foi afetado:
um programa?
uma transação?
um CICS?
uma LPAR?
um Sysplex?
toda a empresa?
Passo 4 — Compare com baseline
Use períodos equivalentes.
Compare terça com terça.
Fechamento com fechamento.
Horário comercial com horário comercial.
Comparações ruins geram conclusões ruins.
Passo 5 — Procure mudanças
Verifique:
deploy;
parâmetros;
WLM;
índices;
volume;
hardware;
storage;
rede;
políticas;
releases;
crescimento de dados.
Passo 6 — Decomponha o tempo
Tempo total pode ser dividido em:
CPU;
I/O;
lock;
queue;
dispatch;
network;
subsystem;
application wait.
Descubra onde o tempo foi gasto.
Passo 7 — Correlacione
Não olhe métricas isoladamente.
Exemplo:
Agora existe uma hipótese forte.
Passo 8 — Valide a causa
Não pare na primeira coincidência.
Confirme com evidências.
Passo 9 — Corrija de forma controlada
Faça uma mudança por vez, quando possível.
Caso contrário, você não saberá qual ação resolveu o problema.
Passo 10 — Meça novamente
Sem medição posterior, não existe prova de melhoria.
14. A questão dos custos
No IBM Z, consumo técnico pode virar custo financeiro.
Considere um programa batch que consome 5% a mais de CPU depois de uma alteração.
Parece pouco.
Mas, se ele executa diariamente, em múltiplas LPARs e durante o pico, pode influenciar:
licenciamento;
capacidade contratada;
necessidade de upgrade;
consumo mensal;
janela batch;
risco operacional.
Imagine que uma otimização evite a ativação antecipada de capacidade adicional.
Ela pode representar economia de centenas de milhares ou até milhões de reais ao longo do tempo.
Não porque o COBOL ficou “mais elegante”, mas porque o sistema passou a usar menos recursos para entregar o mesmo resultado.
Custo de oportunidade
Há também custos indiretos:
Performance é uma disciplina técnica com impacto financeiro direto.
15. Como evoluir na carreira
Para um programador COBOL iniciante, o caminho pode ser gradual.
Etapa 1 — Entenda seu programa
Aprenda a responder:
quanto CPU ele usa?
quanto I/O ele gera?
quais arquivos acessa?
quais tabelas consulta?
quantas vezes executa?
qual volume processa?
qual é o tempo total?
qual parte mais demora?
Etapa 2 — Aprenda a ler ferramentas básicas
Comece com:
SDSF;
JES;
SYSOUT;
mensagens;
accounting;
planos de execução;
estatísticas do job;
EXCP;
CPU time;
elapsed time.
Etapa 3 — Estude z/OS
Aprenda:
address spaces;
dispatch;
WLM;
LPAR;
CPC;
paging;
I/O;
service classes.
Etapa 4 — Estude subsistemas
Escolha uma área:
Aprofunde-se.
Etapa 5 — Aprenda estatística básica
Você não precisa se tornar matemático.
Mas deve compreender:
média;
mediana;
percentil;
desvio padrão;
tendência;
sazonalidade;
correlação;
outlier;
baseline.
Etapa 6 — Aprenda negócio
Pergunte:
qual aplicação é crítica?
qual horário é sensível?
qual transação gera receita?
qual batch não pode atrasar?
qual SLA deve ser protegido?
O melhor engenheiro de performance não é quem conhece mais gráficos.
É quem sabe quais gráficos importam.
16. Erros comuns
Olhar apenas CPU
É o erro mais frequente.
Usar médias que escondem picos
Uma média diária de 40% pode esconder dez minutos a 100%.
Comparar períodos diferentes
Comparar domingo com segunda é perigoso.
Ignorar o negócio
Nem toda anomalia é prioridade.
Ajustar sem medir
Tuning sem baseline é superstição técnica.
Culpar a aplicação cedo demais
Às vezes o problema está no storage, WLM, rede ou infraestrutura.
Culpar a infraestrutura cedo demais
Às vezes um loop COBOL ou SQL ruim é o verdadeiro monstro.
17. Easter eggs do Seaview
Em toda missão do Seaview havia três certezas:
alguma luz vermelha piscaria;
o sonar detectaria algo inexplicável;
alguém sugeriria mergulhar ainda mais fundo.
Na Engenharia de Performance também existem três certezas:
algum gráfico ficará vermelho;
o problema será mais complexo do que parecia;
alguém sugerirá aumentar CPU antes de analisar a causa.
Resista à terceira tentação.
Mais hardware pode mascarar ineficiência.
É como reforçar o casco sem descobrir por que o submarino está colidindo com as rochas.
18. Curiosidades Bellacosa
O mainframe mede performance com profundidade há muitas décadas, muito antes da popularização do termo “observabilidade”.
SMF e RMF já registravam dados operacionais quando muitos sistemas distribuídos ainda dependiam de logs simples.
O WLM não é apenas um agendador. Ele gerencia prioridades com base em objetivos de serviço.
zIIP não é apenas “CPU mais barata”. É uma parte estratégica da arquitetura econômica do IBM Z.
Uma aplicação COBOL eficiente pode continuar valiosa por décadas, justamente porque seu comportamento é previsível, estável e mensurável.
A maioria dos grandes problemas de performance não nasce de uma única causa. Nasce da combinação de pequenas degradações.
Conclusão — O Engenheiro que Escuta o Sonar
A Engenharia de Performance é a arte de ouvir sinais que outros ignoram.
Enquanto muitos enxergam apenas uma tela lenta, o especialista enxerga:
CPU;
I/O;
filas;
locks;
memória;
workload;
prioridade;
arquitetura;
tendência;
custo;
impacto no negócio.
Ele não pergunta apenas:
“Está lento?”
Ele pergunta:
“Desde quando, para quem, em qual camada, sob qual carga, com qual impacto e com quais evidências?”
Para o programador COBOL iniciante, esse conhecimento muda tudo.
Você deixa de escrever programas que apenas funcionam e começa a escrever programas que funcionam bem dentro de um ecossistema complexo.
Você aprende que cada acesso a arquivo tem custo.
Cada SQL tem comportamento.
Cada loop consome capacidade.
Cada chamada remota adiciona espera.
Cada commit influencia logging.
Cada mudança precisa ser medida.
No final da missão, o Seaview retorna à superfície.
A tripulação comemora.
O monstro não era um polvo gigante.
Era um programa que fazia leitura completa de uma tabela de 200 milhões de linhas porque alguém esqueceu de criar o índice correto.
O engenheiro de performance fecha o relatório, toma o último gole de café e deixa uma anotação no diário de bordo:
“Problema resolvido. Causa confirmada. CPU reduzida. Tempo de resposta restaurado. Nenhum submarino perdido.”
E assim termina mais uma viagem ao fundo do mainframe.
