como saber se meus servidores devem usar páginas enormes (tamanho da página de memória)

Question

temos vários servidores no cluster e queremos saber o que, em geral, em quais casos precisamos configurar páginas enormes?

Eu também tenho poucas quastions

1. dose "tamanho da página de memória" é igual a páginas enormes?

no meu servidor linux eu digitei o seguinte comando para verificar o tamanho da página de memória padrão

grep Hugepagesize /proc/meminfo

Hugepagesize: 2048 kB

getconf PAGESIZE

4096

2. mas como todos vêem aqui, obtemos resultados diff, por quê?

3. quais são os riscos ao usar páginas enormes?

4. dose Desativar página enorme transparente - significa desativar a opção PÁGINAS ENORMES?

Answer 1

Hugepages são interessantes quando os aplicativos precisam de grandes mapeamentos para os quais farão acessos aleatórios, porque esse é o pior caso possível para o Translation Lookaside Buffer (TLB). Você troca a granularidade de mapeamento por entradas de TLB.

As páginas, incluindo as páginas de entrada, só podem ser mapeadas para um bloco de memória física do mesmo tamanho e alinhadas a esse tamanho. Portanto, uma página de 2 MB precisa ser mapeada para um limite de 2 MB na RAM física, e uma página de 1 GB precisa ser mapeada para um limite de 1 GB, porque os bits inferiores endereçam dados dentro da página e nenhum deslocamento pode ser adicionado aqui. p>

Isso significa que as páginas iniciais geralmente são reservadas no início do sistema, quando a memória física ainda não está fragmentada. Aplicativos que estão ciente da página do mouse podem usar hugetlbfs para alocá-los.

Você tem que decidir com um parâmetro de kernel se as páginas de entrada devem ter 2 MB ou 1 GB de tamanho, você não pode misturá-las. Páginas normais de 4kB estão sempre disponíveis.

O caso de uso mais comum são as máquinas virtuais (qemu / kvm pode usar as páginas de entrada), onde isso permite manter todo o mapeamento de memória da VM em um pequeno número de entradas de TLB, que nunca são despejadas, portanto, acessos de memória dentro da VM requer uma consulta à tabela de páginas somente dentro do contexto convidado.

Alguns sistemas de banco de dados também suportam páginas de entrada, mas isso geralmente só é útil se você trabalha com grandes conjuntos de dados e índices.

As perguntas:

1. Existem páginas normais (4kB) e páginas enormes (2MB ou 1GB). Quando você consulta o tamanho da página, você obtém o tamanho para páginas normais, quando você consulta o tamanho de página enorme, você obtém a configuração para as páginas grandes. Páginas normais e grandes podem ser usadas em paralelo, mas você não pode misturar tamanhos de páginas enormes.

2. Você obtém resultados diferentes porque essas são duas coisas diferentes. O tamanho das páginas normais é fixado no hardware, por isso não é uma configuração.

3. Páginas enormes precisam ser alocadas antecipadamente e, embora a memória seja tecnicamente "gratuita", ela não pode ser usada para nada além de aplicativos com muita página de conhecimento, de modo que todos esses aplicativos terão menos memória disponível. Isso geralmente não é um problema, porque você usaria as páginas grandes em máquinas dedicadas a aplicativos que exigem muita memória, como VMs ou bancos de dados.

4. Abraces transparentes tentam disponibilizar a memória como buffers e caches (ao contrário do # 3), e tentam dar mais páginas a aplicativos que mapeiam grandes blocos de memória, para que aplicativos que não tenham conhecimento de páginas suficientes possam lucrar com eles - basicamente, uma aplicação que solicite um bloco de memória de 2MB / 1GB receberá uma página, se possível. Se isso ajuda ou prejudica o desempenho depende de seus aplicativos. Se você tem um aplicativo que reconhece a página de tamanho e deseja atribuir a memória manualmente, é necessário desativar o THP, enquanto um sistema que tenha um aplicativo de banco de dados que não entende as páginas maiores provavelmente se beneficiará.

Answer 2

Casos de uso óbvios para páginas enormes são quando PageTables (visível em / proc / meminfo) se torna dezenas de GB. Isso significa grandes gastos de memória e CPU apenas de rastrear sua memória. Isso acontece com pedaços gigantes de memória, grande número de processos ou ambos. Muitas vezes, em aplicativos de banco de dados.

Grandes páginas reduzem significativamente essa sobrecarga porque uma única entrada de tabela de páginas agora endereça muito mais memória, digamos 2.048 KB em vez de 4 KB. (Existem tamanhos diferentes em outras plataformas, o AIX no POWER suporta 16 MB de páginas grandes, por exemplo).

Páginas enormes no Linux não podem ser usadas para armazenamento em cache de arquivos e são irritantes e ineficientes para alguns MB a malloc () para memória não compartilhada. Portanto, o administrador precisa alocar pools de páginas enormes que só podem ser usados para algumas finalidades. Este é um engodo de usar páginas enormes.

Páginas enormes e transparentes (THP) tentam tornar a administração menos irritante ao "fragmentar" automaticamente a memória contígua em páginas enormes. A ideia era que isso torna as páginas enormes pré-alocadas opcionais. Os benefícios são altamente específicos para a carga de trabalho, é possível gastar muito CPU para valer a pena. Desativar o THP significa que você ainda pode usar a alocação de páginas enormes manualmente. Às vezes vale a pena desligar o THP e apenas colocar os segmentos de memória compartilhada do banco de dados em páginas enormes.

Uma última reclamação sobre as páginas enormes do Linux: acho irritante administrá-lo.

• A memória compartilhada usa uma interface, mas para as outras você usa biblioteca hugetlbfs e sistema de arquivos.
• Você pode "desperdiçar" a memória alocando também páginas enormes e não configurando seu aplicativo para usá-lo.
• Esse número de páginas deve ser dimensionado para cada tamanho de host, porque uma contagem de páginas e não uma porcentagem de memória.
• Muitas vezes, a capacidade de alocar páginas enormes é restrita a estar em um grupo, trocando os usuários do banco de dados pode levar a surpreender o desperdício de memória.