Eu ainda não tive ocasião de fazer isso nas máquinas Windows daqui, mas
algumas obs adicionais pra vc pensar :
a. é verdade que com memória alocada em páginas maiores, a quantidade de
acessos necessária deverá diminuir, E também que "dividindo" a RAm em áreas
maiores logicamente menos latches/controles internos vão ser necessários para o
SO a controlar, mas a meu ver o nenefício principal é outro : a área alocada
em huge pages normalmente é LOCKADA, ie, vc não tem nenhum tipo de page steal,
o SO ** não vai ** ficar "tirando" páginas no momento não-usadas ou com pouco
uso dessa área lockada para atender outros processos que demandem memória :
isso é Excelente nos casos em que vc efetivamente quer que a SGA não seja
tocada/mexida/acessada por ninguém de fora do RDBMS, poupando muitas operações
lógicas e latching por parte do SO...
A desvantagem é uma decorrência Óbvia desse lock : a memória que vc indicou
como a ser controlada por huge pages fica permanentemente alocada e servidndo
apenas a SGA : se houver um processo necessitando dessesperadamente de memória
"comum" para a PGA, ou se o So precisar de memória para os fins internos dele,
não tem como alocar nada dentro dessa área marcada como huge page area...
b. a nota de huge pages para Windows ("Using Large Memory Pages on 64-Bit
Windows Systems" (Doc ID 422844.1) no metalink) não cita, mas em outros
ambientes é diretamente declarada a Incompatibilidade entre huge pages e AMM
(Automatic Memory Management) : isso faz todo o sentido, já que a memória
alocada em huge pages VAI estar lockada não tem como se ficar
aumentando/diminuindo ela, nem re-alocando-se pools , ela é um bloco único
alocado de uma vez.... Confirme que o seu ambiente Windows não está usando
nenhum tipo de AMM, preferencialmente...
[]s
Chiappa
