 |
| Bellacosa Mainframe e a falsa sensalçao de rapidez no ibm z |
☕ Um Café no Bellacosa Mainframe
IBM Z: Por que 40% de CPU Livre NÃO Significa que Seu Sistema Está Rápido
Um dos maiores erros dos profissionais iniciantes é olhar apenas para dois números:
CPU = 40%
Memória Livre = 120 GB
e concluir:
"O sistema está folgado."
Enquanto isso...
CICS lento
Batch atrasado
Db2 esperando I/O
Usuários reclamando
Como isso é possível?
Porque no IBM Z a CPU é apenas um dos elementos da equação.
Pense no Mainframe como uma cidade
Imagine uma metrópole.
Ela possui:
avenidas
semáforos
estacionamento
prédios
pessoas
elevadores
Não adianta construir mais prédios se:
o trânsito está parado;
os elevadores são poucos;
o metrô está congestionado.
O mesmo ocorre no IBM Z.
Adicionar memória muitas vezes apenas aumenta o estacionamento.
O congestionamento continua.
A Hierarquia da Memória no IBM Z
No IBM i existe o conceito de Memory Pools.
No z/OS existe uma arquitetura ainda mais rica.
Temos, por exemplo:
Central Storage
↓
Frames de 4 KB
Frames de 1 MB
Frames de 2 GB
↓
Address Spaces
↓
Private Area
Common Area
LSQA
SQA
CSA
ECSA
HVCOMMON
Extended CSA
↓
Applications
CICS
IMS
Db2
MQ
JES2
TSO
USS
Todos competem pela mesma memória física.
Nem toda memória pertence ao seu programa
Muitos imaginam:
Tenho 256 GB.
Meu COBOL pode usar tudo.
Não.
Grande parte da memória é reservada para:
Sistema Operacional
Cross Memory
CSA
Buffers
Coupling Facility
LPAR Management
Hiperspaces
Dataspaces
Java Heap
Db2 Buffer Pools
Seu programa recebe apenas uma pequena parcela.
O verdadeiro Memory Pool do z/OS
Embora o nome seja diferente, existem equivalentes.
No IBM i:
Memory Pool
No IBM Z encontramos:
Address Spaces
Region Size
MEMLIMIT
Dataspaces
Hiperspaces
Pageable Frames
Fixed Frames
Cada workload possui seu "território".
O que acontece quando falta memória?
Suponha um COBOL Batch.
Ele precisa acessar uma página.
Página está na RAM?
SIM
↓
executa imediatamente.
Agora imagine:
Página não está na memória.
O RSM faz:
Page Fault
↓
Localiza a página
↓
Busca no Page Dataset
↓
Move para memória
↓
Programa continua.
Isso é absolutamente normal.
Page Fault NÃO significa erro
Esse é um enorme mito.
Todo sistema gera Page Fault.
Inclusive:
Linux
Windows
Unix
z/OS
O problema é a quantidade.
Imagine:
1 milhão de referências
dessas:
999.900
na memória
↓
ótimo.
Agora imagine:
1 milhão
300.000 Page Faults
Algo está errado.
O que acontece durante um Page Fault?
Enquanto a página é buscada:
CPU
fica esperando.
Observe:
A CPU não trabalha.
Ela espera.
Então o RMF mostra:
CPU = 35%
O gerente conclui:
"Tem CPU sobrando."
Na verdade:
A CPU está parada esperando disco.
Exatamente como no IBM i
O gráfico do IBM i mostra:
CPU baixa
Usuário lento
No IBM Z acontece igual.
Pode existir:
alta paginação;
espera por disco;
latch contention;
lock contention;
enqueue;
Db2 buffer miss.
Tudo isso reduz o uso da CPU.
O verdadeiro inimigo: Waiting
O estado mais caro do sistema não é CPU alta.
É:
Waiting.
No RMF aparecem diversos tipos.
Exemplo:
I/O Wait
Dispatch Wait
Storage Wait
Lock Wait
SRB Wait
Enqueue Wait
Cross Memory Wait
A CPU continua livre.
O usuário continua esperando.
Activity Level no IBM Z
No IBM i existe:
Activity Level
No z/OS o equivalente conceitual é controlado por vários componentes:
WLM (Workload Manager)
SRM (System Resource Manager)
Dispatcher
Dispatching Priority
Service Classes
Velocity Goals
Importance Levels
Ou seja,
não basta existir CPU.
É necessário que o trabalho seja escolhido para executar.
Exemplo
Imagine:
LPAR
20 CPUs
CPU utilizada:
38%
Mesmo assim:
CICS lento.
Por quê?
Porque o WLM pode estar priorizando:
Db2
IMS
Batch Crítico
MQ
TCP/IP
Seu CICS recebe menos dispatch.
Buffer Pool: o Memory Pool do Db2
Outro excelente paralelo.
No IBM i:
DB Faults
No Db2:
Buffer Pool Hit Ratio
Se a página já está no Buffer Pool:
Leitura
0 I/O
Muito rápido.
Se não está:
Disco
↓
I/O
↓
Espera
↓
CPU ociosa
Novamente:
CPU baixa.
Usuário lento.
SQL ruim parece problema de memória
Um exemplo clássico.
SELECT *
FROM CLIENTES
WHERE CPF='123'
Sem índice.
O Db2 faz:
Table Space Scan
Milhões de páginas.
Buffer Pool explode.
Mais I/O.
Mais espera.
Mais paginação.
O usuário diz:
"Precisamos aumentar a memória."
Na verdade:
Era apenas um índice ausente.
CICS também sofre
Um CICS Transaction Server possui:
EDSA
CDSA
UDSA
SDSA
Além disso:
Program Cache
File Control
Temporary Storage
VSAM Buffers
Pouca memória gera:
Storage Violations
SOS (Short on Storage)
GETMAIN Failures
Fragmentação
Adicionar memória ajuda?
Às vezes.
Mas frequentemente o problema é:
Aplicações
↓
não liberam storage.
Batch
Outro exemplo.
Job COBOL.
REGION=0M
Não significa:
memória infinita.
Pode haver:
Virtual Storage Constraint
MEMLIMIT inadequado
Excesso de SORT
Buffers gigantes
LE Heap mal configurado
O erro clássico
O gerente pergunta:
CPU?
Resposta:
40%
Pergunta:
Memória?
250 GB livres.
Conclusão:
Sistema saudável.
Especialista IBM Z responde:
Mostre primeiro:
RMF Monitor III
SMF 70
SMF 72
RMF CPU Activity
Paging Rates
DASD Response Time
WLM Delay Analysis
Db2 Accounting Trace
CICS Statistics
Buffer Pool Hit Ratio
Coupling Facility Delays
Cache Misses
Channel Utilization
Só depois falaremos sobre CPU.
Ferramentas equivalentes ao IBM i
| IBM i | IBM Z |
|---|---|
| WRKSYSSTS | RMF Monitor III |
| WRKACTJOB | SDSF DA / OMEGAMON |
| WRKSHRPOOL | RSM / RMF Storage Reports |
| Collection Services | SMF + RMF |
| Navigator for i | IBM Z Performance and Capacity Analytics (zPCA), OMEGAMON, IBM Z IntelliMagic Vision |
Exemplo real de diagnóstico
Imagine uma LPAR:
8 CPs
2 zIIPs
512 GB RAM
CPU = 42%
Usuários reclamam de lentidão no CICS.
A investigação revela:
CPU não está saturada.
WLM mostra atraso por prioridade de serviço.
O Db2 apresenta baixa taxa de acertos no Buffer Pool BP8K0.
O tempo de resposta do DASD aumentou.
A aplicação executa SQL sem índices adequados, provocando tablespace scans frequentes.
O CICS permanece aguardando I/O em vez de consumir CPU.
Resultado: adicionar mais 128 GB de memória não resolveria o problema. O ganho real veio da criação de índices apropriados, do ajuste do Buffer Pool, da revisão da política do WLM e da otimização do acesso ao armazenamento.
A grande lição para quem trabalha com IBM Z
No mundo IBM Z, desempenho raramente é explicado por um único gráfico de CPU ou pela quantidade de memória instalada. O sistema é um ecossistema onde WLM decide quem executa, o RSM administra a memória, o Db2 gerencia seus Buffer Pools, o CICS controla suas áreas de armazenamento e o subsistema de I/O determina a velocidade com que os dados chegam ao processador.
Um analista júnior costuma perguntar:
"Quanto de CPU e memória temos?"
Um especialista em performance pergunta:
Quem está esperando?
O que está esperando?
Por que está esperando?
A espera é por CPU, armazenamento, bloqueio, paginação, I/O ou prioridade do WLM?
Existe contenção entre workloads?
O gargalo é da infraestrutura ou do desenho da aplicação?
Essa mudança de perspectiva é o que diferencia um operador de um engenheiro de performance.
No IBM Z, o recurso mais valioso não é CPU nem memória. É eliminar esperas desnecessárias. Um sistema eficiente não é o que tem mais hardware, mas o que mantém seus workloads em execução contínua, com o mínimo possível de espera por qualquer recurso.
