Ativei Hugepages em um novo banco de dados Postgres 13, rodando em EL8 Linux (huge_pages=try), e percebi que o Shmem ainda está crescendo e nenhuma HugePages está sendo usada ainda (mas vejo que as HugePages estão configuradas). THP estão desativados.
Tentei fazer SELECT * em uma tabela grande e o shmem cresceu alguns GB, mas ainda nenhuma página enorme está sendo usada.
A última vez que configurei Hugepages em um banco de dados Postgres, acho que a mesma coisa aconteceu, mas eventualmente ele começou a usar HugePages e o uso do Shmem caiu para quase zero (presumivelmente apenas bloqueios e outros enfeites estão sendo usados no Shmem).
Qual é o motivo para que páginas enormes comecem a ser usadas em vez de shmem? O que acontece internamente para orientar o comportamento/decisão?
Presumivelmente, preciso de uma operação que use páginas anônimas no Postgres, talvez SELECT * sejam todas páginas de arquivo? Eu acho que não. Existe uma consulta melhor (inofensiva, discreta, exceto com uso intensivo de RAM) para forçar o Postgres a usar um monte de páginas anon (páginas enormes)?
Atualmente (pág. 16 e anteriores) o postgresql usa páginas enormes apenas para alocar um segmento de memória compartilhada e, consequentemente, somente ao iniciar o SGBD. Isso não muda na operação futura do banco de dados.
Ao usar
huge_pages=tryo SGBD na inicialização, primeiro tentaremos solicitar um segmento de memória do sistema operacional usando páginas enormes; se isso falhar, ele solicitará um segmento de memória regular. Como seu banco de dados não conseguiu alocar páginas enormes na inicialização, isso significa que não havia páginas enormes gratuitas suficientes.Gostaria de chamar a atenção para o fato de que estamos falando aqui de todo o segmento de memória compartilhada. Não é igual ao tamanho de
shared_buffers, mas é 2-3% maior, pois o segmento de memória compartilhada inclui muitas outras estruturas de dados que também devem ser compartilhadas entre processos de banco de dados.