☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta paging. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta paging. Mostrar todas as mensagens

terça-feira, 31 de março de 2026

🔥 SEUS DADOS NÃO MORAM NO DISCO… ELES VIAJAM PELO UNIVERSO DO z/OS 😳

 

Bellacosa Mainframe num mergulho no mundo storage do z/os

🔥 SEUS DADOS NÃO MORAM NO DISCO… ELES VIAJAM PELO UNIVERSO DO z/OS 😳

O guia proibido de Storage Management que revela como memória, disco e sysplex trabalham juntos (e quase ninguém entende)

Você acha que seu dataset “fica no disco”?

👉 Não fica.

No z/OS, dados:

  • sobem pra memória
  • descem pra disco
  • migram pra fita
  • aparecem em outro LPAR
  • e até existem fora do seu address space

💥 “No mainframe, dado não tem endereço fixo… tem estratégia.”

Se você quer sair do nível “usuário” e pensar como engenheiro de sistema, esse é o mapa completo 👊🔥


🧠 1. ADDRESS SPACE — O UNIVERSO DO PROGRAMA

Cada programa roda em um address space isolado.


🔥 O que isso significa?

  • memória protegida
  • ambiente independente
  • controle total do sistema

💡 Insight

cada address space é um “universo privado”


⚡ 2. 64-BIT ADDRESSING — MEMÓRIA INFINITA (QUASE)

Com 64 bits:

👉 até 16 EXABYTES


🔥 Evolução histórica

EraLimite
24-bit16MB 😱
31-bit2GB
👉 64-bit16EB 🤯

💡 Tradução Bellacosa

“acabou a desculpa de falta de memória”


🧠 Uso real

  • Java
  • Db2
  • middleware
  • grandes buffers

🧩 3. DAT — A MÁGICA DA TRADUÇÃO

DAT (Dynamic Address Translation):

👉 converte endereço virtual → real


🔥 Sem DAT:

  • programa quebraria
  • memória não funcionaria

💡 Tradução

“você nunca acessa memória real diretamente”


🧠 4. STORAGE REQUESTS — COMO A MEMÓRIA É PEDIDA

Programas pedem memória via:

  • GETMAIN
  • STORAGE OBTAIN

🔥 O sistema decide:

  • onde alocar
  • em qual subpool
  • com qual proteção

💡 Insight

memória é gerenciada, não livre


🧱 5. SUBPOOLS — ORGANIZAÇÃO INTERNA

Memória é dividida em:

👉 subpools


🔥 Exemplos:

  • SP0 → sistema
  • SP229 → usuário

💡 Tradução

“cada tipo de dado tem seu bairro”


🌍 6. DATA SPACES & HIPERSPACES — FORA DO ADDRESS SPACE

🔹 Data Spaces

  • dados fora do address space
  • acessados via AR

🔹 Hiperspaces

  • alta performance
  • acesso indireto

🔥 Tradução Bellacosa

“memória extra fora do seu universo”


🧠 Exemplo

Programa → usa Data Space → grande volume de dados

⚡ 7. PAGING — QUANDO A MEMÓRIA NÃO CABE

Se falta memória:

👉 dados vão para disco (paging)


🔥 Fluxo

Memória cheia

página vai para DASD

quando necessário → volta

💡 Problema

👉 excesso de paging = sistema lento 💀


💾 8. FLASH STORAGE — O TURBO MODERNO

Flash (SSD):

  • baixa latência
  • alta velocidade
  • ideal para OLTP

💡 Uso

  • Db2
  • logs
  • datasets críticos

🔗 9. PARALLEL SYSPLEX — MEMÓRIA COMPARTILHADA ENTRE SISTEMAS

Aqui fica poderoso 😄


🔥 O que é?

Vários z/OS trabalhando juntos:

👉 como um só sistema


💡 Elementos:

  • LPARs
  • Coupling Facility (CF)
  • links de comunicação

🧠 Exemplo

LPAR A → acessa dado
LPAR B → acessa o mesmo dado

💡 Tradução

“dados compartilhados em tempo real”


🧠 10. COUPLING FACILITY (CF) — O CÉREBRO COMPARTILHADO

🔹 Função:

  • lock management
  • cache
  • filas

🔥 Tipos:

  • Internal CF
  • External CF

💡 Tradução Bellacosa

“CF = memória compartilhada do sysplex”


⚡ 11. DUPLEXING — ZERO PERDA

🔥 O que faz?

  • duplica dados
  • garante disponibilidade

💡 Exemplo

CF primário → falha
CF secundário → assume

🧨 Curiosidade

Sistema continua rodando sem impacto 😳


🧠 12. CF OPERATIONS — O QUE ACONTECE POR TRÁS

CF gerencia:

  • locks
  • buffers
  • filas

💡 Uso real

  • Db2 data sharing
  • CICS
  • IMS

⚙️ 13. STORAGE + I/O + CPU — TUDO CONECTADO

Nada funciona isolado:

Memória → I/O → CPU → WLM → Storage

💡 Insight

performance é resultado do conjunto


🔄 14. PASSO A PASSO COMPLETO

Programa inicia

recebe address space

pede memória (GETMAIN)

DAT traduz endereço

usa data space se necessário

paging ocorre se faltar memória

dados vão para disco/flash

sysplex compartilha dados via CF

duplex garante disponibilidade

🧨 CURIOSIDADES (NÍVEL ROOT)

🤯 1. Você não controla diretamente onde o dado está


🔥 2. Dados podem estar fora do seu address space


💀 3. Paging excessivo mata performance


🧠 4. Sysplex permite vários sistemas compartilharem dados


⚡ 5. CF é o segredo da alta disponibilidade


🎯 RESUMO FINAL

✔ Address space = isolamento

✔ 64-bit = escala absurda

✔ DAT = tradução

✔ Subpools = organização

✔ Data space = expansão

✔ Paging = fallback

✔ Flash = velocidade

✔ Sysplex = escala

✔ CF = coordenação

✔ Duplexing = resiliência


💥 FRASE FINAL

“No z/OS, dados não ficam armazenados… eles são orquestrados entre memória, disco e múltiplos sistemas em tempo real.”

sexta-feira, 30 de agosto de 2024

IBM Z: Por que 40% de CPU Livre NÃO Significa que Seu Sistema Está Rápido

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 iIBM Z
WRKSYSSTSRMF Monitor III
WRKACTJOBSDSF DA / OMEGAMON
WRKSHRPOOLRSM / RMF Storage Reports
Collection ServicesSMF + RMF
Navigator for iIBM 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:

  1. CPU não está saturada.

  2. WLM mostra atraso por prioridade de serviço.

  3. O Db2 apresenta baixa taxa de acertos no Buffer Pool BP8K0.

  4. O tempo de resposta do DASD aumentou.

  5. A aplicação executa SQL sem índices adequados, provocando tablespace scans frequentes.

  6. 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.

 

quinta-feira, 29 de junho de 2023

Paging no IBM Z — Quando a memória começa a “respirar fundo”

 

Bellacosa Mainframe comenta sobre paginação de memoria no ibm z 

☕ Um Café no Bellacosa Mainframe

Paging no IBM Z — Quando a memória começa a “respirar fundo”

Se a tela anterior mostrava o cérebro relaxado do sistema…
esta aqui mostra a respiração dele.

PAGING RATE IN: 28/SEC
IN DELAY: 0.6 %

Pode parecer algo obscuro, mas na prática isso responde a uma pergunta crucial:

👉 A memória do sistema está sobrando… ou está começando a faltar?

Vamos traduzir isso para o português humano ☕


TSO SDSF Simulator


🧠 Primeiro: o que é Paging?

Mesmo um mainframe gigantesco não mantém tudo na memória ao mesmo tempo.

Quando a RAM começa a ficar cheia, o sistema faz algo muito inteligente:

➡️ Move partes pouco usadas da memória para o disco
➡️ Libera espaço para o que está sendo usado agora

Isso se chama:

📦 PAGING (ou paginação)

💡 Analogia Bellacosa™:

Imagine sua mesa de trabalho.

  • Papéis importantes → ficam na mesa (RAM)

  • Papéis menos usados → vão para a gaveta (disco)

  • Quando precisa → você pega da gaveta de volta

O IBM Z faz isso bilhões de vezes por dia.


⚡ PAGING RATE IN — “Quantos papéis estão voltando da gaveta”

👉 28/SEC = 28 páginas por segundo voltando do disco para a RAM

Isso indica atividade de paginação para dentro da memória.

Quanto maior esse número:

  • Mais o sistema está buscando dados no disco

  • Mais lentidão pode ocorrer

  • Pode indicar pressão de memória

Mas aqui vem a surpresa…

👉 28 por segundo é praticamente nada para um mainframe

Um z/OS sob estresse pode chegar a milhares por segundo.

💬 Fofoquinha técnica:

Existem ambientes bancários onde o paging é tão bem ajustado que passa dias em zero.


⏳ IN DELAY — “Usuários esperando por memória”

👉 0.6%

Esse indicador mostra quanto tempo tarefas ficaram aguardando páginas chegarem do disco.

Em outras palavras:

➡️ Quanto o sistema está “segurando a fila” por falta de memória imediata.

Como interpretar?

  • 0% → perfeito

  • < 1% → excelente

  • 1–5% → atenção

  • 10% → problema sério

👉 0.6% = sistema saudável e tranquilo


🏥 Diagnóstico geral desta tela

💚 O sistema está:

✔️ Fazendo pouca paginação
✔️ Quase ninguém esperando
✔️ Memória bem dimensionada
✔️ Performance intacta

Em termos humanos:

👉 Ele está respirando calmamente, não ofegante.


🧓 História curiosa

Nos anos 70 e 80, tuning de paging era uma arte quase mística.

Operadores ajustavam:

  • Tamanhos de page dataset

  • Algoritmos de working set

  • Prioridades de jobs

  • Balanceamento manual

Hoje, o z/OS faz isso com uma sofisticação absurda.


🤫 Easter Egg Mainframe

Existe um ditado famoso entre sysprogs:

“Paging is normal. Thrashing is panic.”

Thrashing é quando o sistema passa mais tempo movendo páginas do que executando trabalho.

Felizmente, esta tela está MUITO longe disso.


🕵️ Fofoquice corporativa

Algumas instituições configuram alertas automáticos quando:

👉 IN DELAY ultrapassa 2%
👉 Paging rate dispara subitamente

Porque isso pode indicar:

  • Pico inesperado de transações

  • Job descontrolado

  • Vazamento de memória

  • Ataque ou loop

  • Batch gigante rodando fora da janela


🧃 Explicação ultra simples

Se o IBM Z fosse um restaurante:

  • Cozinha (RAM) → área principal

  • Despensa (disco) → armazenamento

  • Garçom trazendo ingredientes → paging IN

  • Clientes esperando prato → IN DELAY

👉 Aqui os pratos estão saindo rápido.
Ninguém está reclamando.


🚀 Por que isso é impressionante?

Porque estamos falando de sistemas que:

  • Processam milhões de transações por segundo

  • Mantêm bancos inteiros online

  • Não podem travar

  • Não podem “ficar lentos”

  • Não podem perder dados

E tudo isso com números que parecem… tranquilos.


☕ Conclusão

Esta tela é um dos sinais vitais mais importantes do z/OS.

Ela responde silenciosamente:

👉 “Estamos confortáveis ou começando a sufocar?”

Neste caso:

💚 Sistema confortável
💚 Memória adequada
💚 Performance estável
💚 Nenhum drama no horizonte

O tipo de tela que faz um sysprog sorrir discretamente.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...