Configurando HugePages no Oracle Linux

Introdução

A memória RAM no kernel do sistema operacional é fragmentada em pequenos pedaços para que possa ser manipulada pela CPU, cada pedaço de memória é conhecido como uma página de memória. Internamente cada CPU tem um componente chamado Memory Management Unit (MMU) que é uma tabela com ponteiros para cada página de memória RAM disponível. O tamanho padrão de cada página de memória no Oracle Linux é 4 Kb.

Aplicação

Para permitir que a CPU manipule mais memória RAM, existem dois caminhos possíveis:

  • Aumentar a quantidade de páginas manipuladas pela CPU (Default)
  • Aumentar o tamanho de cada página de memória manipulada pela CPU (HugePages)

A primeira opção é o padrão, mas torna-se muito custoso para a CPU conforme a quantidade de memória RAM aumenta e a partir de certo ponto torna-se um gargalo para o sistema. A segunda opção é menos custosa para a CPU porque a quantidade de ponteiros necessários para alocar a mesma quantidade de memória RAM é muito menor.

Quando o tamanho de página de memória é configurado para um tamanho maior do que o padrão, que no Oracle Linux é 2048 Kb, essas páginas são conhecidas como “HugePages” (grandes páginas). A Tabela 1 apresenta um comparativo com as quantidades de ponteiros na MMU necessários em configurações sem HugePages e com HugePages, respectivamente.

Tabela 1: Comparativo de quantidade de ponteiros na MMU com e sem Hugepages

Benefícios

Conforme apresentado na Tabela 1, o uso de HugePages resulta em uma redução de 99,80% na quantidade de páginas de memória na MMU, resultando uma redução proporcional no uso de CPU empregados no gerenciamento de memória.

Outro benefício do HugePages é que essas páginas de memória não são candidatas para SWAP no sistema operaciona, isso significa que a memória RAM alocada para a SGA nunca será submetida a SWAP, garantindo o desempenho máximo nas operações de buffer do Oracle.

Configuração no Linux

A configuração de HugePages requer alterações em parâmetro do Kernel do Linux e do Oracle, sendo as vezes necessário reiniciar o servidor para que as alterações sejam efetivadas.

Usualmente tratamos as estruturas de memória do Oracle Database em Gigabytes (Gb), mas os tamanhos das páginas de memória no Linux são tratados em Kilobytes (Kb). Para definir a quantidade de páginas que devem ser configuradas no Linux é necessário converter a memória em GB para KB. Para simplificar a conta, podemos converter ambos para Megabytes (Mb):

Convertendo SGA de GB para MB 
Gb => Mb = X * 1024 
10GB * 1024 = 10.240 MB

Convertendo HugePages de KB para MB 
Kb => MB = X / 1024 
2048 KB / 1024 = 2 Mb

Para habilitar o HugePages no Linux, é necessário alterar o parâmetro do kernel nr_hugepages que indica a quantidade de páginas de memória RAM que serão alocadas como HugePages.

Para determinarmos o valor deste parâmetro, dividimos o valor da SGA em MB pelo tamanho da página em MB. Para a SGA de 10 GB, devemos configurar o valor para o parâmetro indicando 5.120 páginas, conforme a seguir:

nr_hugepages = SGA (MB) / Tamanho da Página (MB) 
nr_hugepages = 10.240 / 2 
nr_hugepages = 5.120
(Reomenda-se considerar uma margem de sobra. Esse valor na prática poderia ser 5.125, por exemplo)
A Oracle disponibiliza aqui um script shell para realizar o cálculo.

DICA: No Oracle Linux que tem o tamanho de página igual a 2048 KB (2MB), de fato o atalho para o cálculo é simplesmente dividir a quantidade da memória SGA por 2 diretamente.

Configuração no Oracle

A instância deve estar configurada com ASMM (Automatic Shared Memory Management) , o Oracle não suporta HugePages com AMM (Oracle Memory Management).

Relembrando parâmetros de ASMM vs AMM:

ASMM: sga_max_size e sga_target
AMM: memory_max_target e memory_target

Forçando o uso de HugePages

A partir da versão 11.2.0.2, a Oracle incluiu um parâmetro para controlar se a SGA será alocada em HugePages, o parâmetro use_large_pages que pode ser configurado com os seguintes valores:

FALSE: Nunca usa HugePages, deve ter memória em páginas padrão disponível;
TRUE (padrão): Usa HugePages se houver memória disponível;
ONLY: Usa somente HugePages, falha no STARTUP se não tiver memória disponível.

New Feature 19c:

AUTO: Aloca o que der em Hugepages, o restante é alocado em memória regular. 
AUTO_ONLY: A instância inicia somente se a SGA for alocada totalmente em Hugepages.

No 19c, AUTO_ONLY é default e exclusivo para banco de dados rodando em Exadata.

Na nova configuração, valor AUTO tem comportamento similar a TRUE e AUTO_ONLY tem comportamento similar a ONLY. Na prática, isso parece uma transição da Oracle para padrão de nomeclatura mais amigável, visto que TRUE já era alto (aloca o que der em Hugepages, o que sobrar aloca em memória regular – configuração mixada).

Exemplo

1. Verificando o tamanho da página de HugePages no Linux (2048K = 2M):

$ grep Hugepagesize /proc/meminfo
Hugepagesize:       2048 kB

2 Verificando a configuração da SGA no Oracle (5G = 5.120M):

SQL> show parameter sga_max_size;
NAME                  TYPE        VALUE
--------------------- ---------- --------------
sga_max_size          big integer 5G

3 Calculando a quantidade de páginas necessárias:

nr_hugepages = SGA (MB) / Tamanho da Página (MB)
nr_hugepages = 5.120 / 2
nr_hugepages = 2.560

4 Configurando o parâmetro nr_hugepages no Linux:

$ su root
Password:********
# cp /etc/sysctl.conf /etc/sysctl.conf.bkp
# echo 'vm.nr_hugepages=2570' >> /etc/sysctl.conf
# grep hugepages /etc/sysctl.conf
vm.nr_hugepages=2570
# exit

ATENÇÃO! Confirme que está configurando o parâmetro nr_hugepages com um valor correto, se você configurar esse parâmetro com um valor igual ou maior a quantidade total de memória do servidor, ele poderá não iniciar após reboot, sendo necessário ajustar via console (quando tem).

5 Reiniciando o servidor:

$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Mon Mar 23 21:10:01 2020
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> exit
$ su root
Password:
# reboot

6 Servidor reiniciado. Verificando memória em HugePages livre:

$ grep Huge /proc/meminfo
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:    2570
HugePages_Free:     2570
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

7 Iniciando instância Oracle

SQL> startup;
ORACLE instance started.

Total System Global Area 5368705448 bytes
Fixed Size                  9146792 bytes
Variable Size             587202560 bytes
Database Buffers         4764729344 bytes
Redo Buffers                7626752 bytes
Database mounted.
Database opened.
SQL> exit

8 Confirmando que a SGA alocou memória com HugePages no alert.log:

$ cd $ORACLE_BASE/diag/rdbms/up19/up19/trace/
$ grep -A 2 PAGESIZE alert_up19.log

Imagem cortada com as duas últimas ocorrências. Observe que no startup anterior, a instância havia alocado memória com págias de 4k (default) e no startup após a configuração, alocou memória com páginas de 2048K (HugePages).

PAGESIZE: Tamanho da página utilizada
AVAILABLE_PAGES: Quantidade de páginas disponível no Linux
EXPECTED_PAGES: Quantidade de páginas efetivamente necessárias
ALLOCATED_PAGES: Quantidade de páginas efetivamente alocadas
ERROR: Mensagem de erro quando o startup da instância falha

9 Verificando páginas de HugePages utilizadas no Linux:

$ grep Huge /proc/meminfo
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:    2570
HugePages_Free:       14
HugePages_Rsvd:        6
HugePages_Surp:        0
Hugepagesize:       2048 kB

Observe que HugePages_Free agora constam somente 14 páginas livres, HugePages_Rsvd indica 6 páginas reservas. A margem de sobra configurada neste exemplo foi de 10 páginas, mas não é obrigatório, muitos ambientes são configurado com até 1 página como margem de sobra.

Dicas

Se você quer analisar o histórico de uma instância e verificar se a mesma alocou memória em Hugepages no último startup, leia o post Verificando se a Instância Alocou a SGA em HugePages no Último Startup

Em ambiente RAC, a configuração de Hugepages pode ser diferente em cada instância, mas não é recomendado. Em um cluster, configure os parâmetros de SGA e use_large_pages igualmente em todas as instâncias.

Em um ambiente com consolidação (vários bancos de dados no mesmo servidor), é recomendado definir inicialmente o total de memória que será dedicada ao Oracle Database, decidir qual o limite será usado para SGA e configurar a Hugepages previamente no servidor já com o valor total. Isso permitirá criar novas instâncias ou ajustar a memória das instâncias existentes sem ter que modificar as configurações a nível de SO frequentemente.

Evite configuração mixada, exemplo: Você tem um servidor com 512 GB de memória com Hugepages configurada para suportar 380 GB de SGA e você quer aumentar a SGA para 400 GB, se você simplesmente aumentar a SGA para 400 GB e alterar o parâmetro use_large_pages para TRUE ou AUTO (19c), isso resultará em 194.560 páginas de MMU para acomodar 380 GB em Hugepages e 5.242.880 páginas para acomodar os 20 GB de memória regular. O esforço da CPU seria mais de 26x maior para gerenciar essa pequena porção de memória que representaria apenas 5% da SGA total.

Reiniciar o servidor nem sempre é necessário, mas é uma boa prática.

Conclusão

Este post apresentou o conceito básico do recurso de HugePages no Linux e como ele pode ser benéfico para o banco de dados Oracle, assim como apresentou como calcular e planejar a configuração. Por fim, foi apresentado exemplos práticos de todos os passos que devem ser executados no Linux e no Oracle Database.

Referências

REDHAT: 5.2. HUGE PAGES AND TRANSPARENT HUGE PAGES
Database Administrator’s Reference: HugePages
Database Reference: USE_LARGE_PAGES
Pythian Blog: How Linux Hugepages Work To Improve Oracle Performance

1 thought on “Configurando HugePages no Oracle Linux”

Leave a Reply

Scroll to Top

Discover more from Blog do Dibiei

Subscribe now to keep reading and get access to the full archive.

Continue reading