O documento discute o conceito de bufferpool no DB2 e como fixar páginas de bufferpool na memória central para melhorar o desempenho. Ele explica que fixar páginas de bufferpool associadas a tablespaces de uso intenso pode reduzir o tempo CPU do DB2 em cerca de 30% ao evitar operações frequentes de pagefix e pagefree, embora seja necessário monitorar os indicadores de memória para evitar problemas.

1. Palestra: Fixando Bufferpool do DB2 v8 em memórias gigantes
1. Conceito de Bufferpool
Começando pelo início se deve dizer que bufferpool é um conjunto de buffers de I/
O (área na memória virtual para onde o bloco físico de um data set é copiado ou de
onde é lido durante uma operação de I/O) todos com o mesmo tamanho. A
implementação de bufferpools tem um claro viés de melhorar em geral o desempenho
informático.
Eles servem principalmente para evitar operações de I/O randômicas. O I/O é
evitado quando o aplicativo revisita o dado ou o index, que via uma prévia operação de
I/O foi carregado e mantido no tal bufferpool pelo software que administra tais dados.
É lógico que o I/O mais rápido é o inexistente - que os fabricantes de storage não nos
escutem (aliás, eles devem odiar bufferpools – rsrsrs).
No caso de I/O seqüencial a existência de um bufferpool com uma quantidade
significativa de buffers permite o paralelismo na execução task do aplicativo na CPU
concorrente com a execução de operações de I/O no data set. Além disso, vários
blocos podem ser transmitidos por I/O, o que diminui consistentemente o tempo
connect total para transferir o data set em questão.
DB2 usa efetivamente bufferpools para conter suas páginas. Esses podem ser
localizados na área privada do DBM1 address space (abaixo e acima da barra), ou em
data spaces, ou em hiper spaces (não recomendado).
Continuando a discorrer sobre conceitos primitivos, e, portanto, correndo o risco
de enfadá-los vamos sumarizar as idéias básicas de memória virtual (lembram do 155-
II?).
Página é um conjunto de 4K endereços virtuais alinhados em endereços múltiplos
de 4K. Talvez seja uma surpresa para vocês, mas agora é possível, em z/OS se ter,
opcionalmente, páginas de 1 M endereços... Os endereços de uma página são
referenciados pela CPU para acessar instruções e seus operandos. Páginas se
localizam virtualmente em address spaces. A criação dos endereços de uma página é
requerida por programas aplicativos através dos APIs Getmain e IEARV64 (ver
abaixo).
GETMAIN
LC,LA=length addr,A=addr
LU,LA=length addr,A=addr
VC,LA=length addr,A=addr
VU,LA=length addr,A=addr
EC,LV=length value,A=addr
EU,LV=length value,A=addr
VRU,LV=(maximum length value, minimum length value)
SP=subpool nmbr

2. IARV64
REQUEST=GETSTOR,
COND=NO,
COND=YES,
SEGMENTS=segments,
FPROT=YES,
FPROT=NO,
SVCDUMPRGN=YES,
SVCDUMPRGN=NO
Parâmetros definem a localidade da nova página:
• AS private or common area below the line
• AS private area or common above the line
• AS private and common area above the bar
• Uma página também pode ser criada em Dataspaces e Hiperspaces
2. Conceito de Page Fixing
O conteúdo físico (instruções e operandos) apontado pelos endereços de uma
página pode residir na memória central em frames de 4 KB ou em slots (blocos de I/O)
também de 4 KB localizados em página data sets. Neste caso, tal conteúdo foi roubado
pelo z/OS, da memória central por serem pouco referenciados e haver falta de frames
disponíveis.
Veja no relatório abaixo de RMF Monitor III (STORF) o address space
DB2MDBM1. Suas páginas se distribuem entre 64897 (TOTAL) contidas em frames da
memória central e 3212 (AUX) em slots de pagé data sets.

3. Fixar uma página significa que a partir do momento da fixação, esta página não
está disponível para ser roubada de um frame para um slot (page out), mesmo que
tenha sido pouco referenciada. A necessidade de se fixar uma pagina tem a ver com a
manutenção da integridade. Veja no relatório anterior que das 64897 páginas contidas
em frames, 432 estão fixas.
O mais freqüente motivo para fixar páginas seria durante a execução de I/O,
quando tal página contiver um buffer de I/O sendo referenciado nessa operação de I/O.
Como o canal apenas trabalha com endereços reais (não tem DAT), a página contendo
um I/O buffer ativo não pode ser roubada.
Após o término do I/O a página tem que ser “desfixada” via a função Pagefree do
z/OS.
3. Implementando DB2 Bufferpool Pagefix
Usando-se a função Trace do z/OS (exemplificada abaixo) se percebeu que a
execução freqüente de Pagefix e Pagefree consome muita CPU.
PR ASID WU-ADDR- IDENT PSW----- ADDRESS- TIMESTAMP-REC
01- 0018 008E3E88 SSCH 070C20000241FC38 C1668821970F9001
01 -0018 00000000 I/O 070C2000810D6C6C C166882197122001
Portanto a idéia seria evitar esse consumo de CPU. Para isso vamos fixar por
tempo indefinido, certos bufferpools do DB2 associados a table spaces de uso mais
intenso. Dessa maneira estaremos consumindo mais central storage frames que agora
ficam indisponiveis para outras páginas.
É esperado cerca de 30% de economia no DB2 CPU time. Isto implica em
economia de hardware e também de software, pois teremos menos MSUs/hora
consumidos.
Vamos ver se você imagina agora o que vou escrever…
Isso mesmo. É preciso ter cuidado de não se matar o doente com o remédio.
Isto quer dizer que a implementação da função tem de ser acompanhada pela
inspeção constante dos indicadores da saúde da memória como: Highest UIC, Page
Fault Rate, Available Queue size.
Também se recomenda criar mais local page data sets.
Se você um dia implementar tal função por favor me envie pela internet
(salla@maffei.com.br) seus comentários, para que eu os espalhe aos ventos...
Contribua para um mundo melhor. Ensine z/OS para os jovens e coma menos
animais...