Configurar a PMEM (memória persistente) para o SQL Server em Linux

Aplica-se a: SQL Server no Linux

Este artigo descreve como configurar a memória persistente (PMEM) para SQL Server 2019 (15.x) e versões posteriores no Linux.

Overview

O SQL Server 2019 (15.x) adiciona suporte à memória persistente para acelerar várias operações que consomem muito armazenamento.

Com um sistema de arquivos consciente do PMEM, o mapeamento de memória (mmap()) dá às aplicações do espaço do usuário acesso direto aos dados dos arquivos. Quando um mapa de memória é criado para um arquivo, o aplicativo pode emitir instruções de carregamento/armazenamento que contornam a camada de armazenamento.

Note

Esse acesso direto é chamado de método de acesso a arquivos iluminado do ponto de vista da aplicação de extensão do host, que é como o SQL Server interage com o sistema operacional do host, usando a Camada de Abstração da Plataforma SQL (SQLPAL).

Este artigo mostra como configurar memória persistente para SQL Server em Linux.

Criar namespaces para dispositivos PMEM

Configurar os dispositivos

No Linux, use o utilitário ndctl.

  • Instale ndctl para configurar o dispositivo PMEM com Instalar NDCTL.
  • Use ndctl para criar um namespace. Os namespaces são intercalados pelos NVDIMMs da PMEM e podem fornecer tipos diferentes de acesso ao espaço de usuário para regiões de memória no dispositivo. fsdax é o padrão e o modo desejado para SQL Server.
ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

O fsdax modo armazena metadados por página na memória do sistema. A --map=dev opção é recomendada porque armazena os metadados diretamente no namespace. Armazenar metadados na memória com --map=mem é experimental.

Use ndctl para verificar o namespace.

Após a saída de exemplo, segue:

# ndctl list -N
{
  "dev":"namespace0.0",
  "mode":"fsdax",
  "map":"dev",
  "size":4294967296,
  "sector_size":512,
  "blockdev":"pmem0",
  "numa_node":0
}

Criar e montar o dispositivo PMEM

Por exemplo, com XFS:

mkfs.xfs -f /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax
xfs_io -c "extsize 2m" /mnt/dax

Por exemplo, com ext4:

mkfs.ext4 -b 4096 -E stride=512 -F /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax

Considerações técnicas

  • Bloquear alocação de 2 MB para XFS ou ext4, conforme descrito anteriormente
  • O alinhamento incorreto entre alocação de bloco e mmap resulta em um fallback silencioso para 4 KB
  • Os tamanhos de arquivo devem ser múltiplos de 2 MB (módulo 2 MB)
  • Não desabilite THP (páginas enormes transparentes) (habilitadas por padrão na maioria das distribuições)

Depois de ndctl configurar, criar e montar o dispositivo, você pode colocar arquivos de banco de dados nele ou criar um novo banco de dados.

Você pode armazenar os arquivos de dados do SQL Server (.mdf, ) e tempdb arquivos em um dispositivo PMEM no fsdax modo com o .ndfseguinte comando. Não use esse modo para armazenar os arquivos de log do SQL Server (.ldf), porque o log de transações requer armazenamento que forneça garantias atômicas de setor:

ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

Antes de definir a opção de mapa no comando anterior, tenha em mente os seguintes pontos:

  • Para melhor desempenho ao acessar e atualizar essas entradas de página NVDIMM para este dispositivo, use -map=mem
  • Se a capacidade do NVDIMM for muito grande (maior que 512 GB), defina -map=dev, o que afeta a taxa de transferência de E/S e reduz o desempenho

Para arquivos de log do SQL Server em dispositivos PMEM, configure os dispositivos PMEM para usar Tabela de Tradução de Setor/Bloco (BTT). Essa configuração fornece a atomicidade setorial que arquivos de log do SQL Server exigem para essa tecnologia de armazenamento. Realize validações de desempenho da carga de trabalho. Compare o desempenho dos logs do SQL Server para sua carga de trabalho entre esta solução e os melhores SSDs NVMe, e então selecione aquele que melhor atende às suas necessidades.

ndctl create-namespace -f -e namespace0.0 --mode= sector

Desabilitar a função de esvaziamento forçado

Como os dispositivos PMEM são seguros para O_DIRECT (E/S diretos), você pode desabilitar o comportamento de liberação forçada.

Note

Um sistema de armazenamento pode garantir que quaisquer gravações em cache ou em etapas sejam seguras e duráveis, garantindo que as gravações no dispositivo residam em um meio que persista entre travamentos do sistema, resets de interface e falhas de energia, e que o próprio meio seja redundante de hardware.

  • Os arquivos de banco de dados (.mdf e .ndf) e do log de transações (.ldf) não usam writethrough e alternatewritethrough por padrão no SQL Server 2017 (14.x) CU 6 e versões posteriores, pois usam o comportamento de liberação forçada. A flag de rastreamento 3979 desativa o comportamento de limpeza forçada para arquivos de log de banco de dados e transações, e utiliza a writethrough lógica e alternatewritethrough .

  • Outros arquivos que o SQL Server abre com FILE_FLAG_WRITE_THROUGH, como snapshots de banco de dados, snapshots internos para verificações de consistência de banco de dados (DBCC CHECKDB), arquivos de rastreamento de profiler e arquivos de rastreamento de eventos estendidos, utilizam as writethrough otimizações e alternatewritethrough .

Para obter mais informações sobre as alterações introduzidas no SQL Server 2017 (14.x) CU 6, confira KB 4131496. Para obter mais informações sobre o funcionamento interno do acesso forçado à unidade (FUA), confira Internos do FUA.

Recurso de subsistema de E/S de FUA (Acesso forçado à unidade) e SQL Server

Algumas distribuições do Linux com suporte implementam o FUA (Acesso Forçado à Unidade) no nível do subsistema de E/S para garantir a durabilidade dos dados. O SQL Server aproveita esse recurso para fornecer desempenho de E/S eficiente e confiável para cargas de trabalho do Linux. Para saber mais sobre o suporte do FUA pela distribuição do Linux e o impacto dele no SQL Server, confira SQL Server em Linux: elementos internos do FUA (acesso forçado à unidade).

O suporte para FUA no subsistema de E/S foi introduzido no SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 e Ubuntu 18.04. No SQL Server 2017 (14.x) CU 6 e versões posteriores, use a configuração a seguir para habilitar Entrada/Saída (E/S) de alto desempenho e eficiente com FUA no SQL Server.

Use esta configuração recomendada se as seguintes condições forem atendidas:

  • SQL Server 2017 (14.x) CU 6 e versões posteriores

  • Distribuição e versão do Linux que dão suporte ao recurso FUA (começando com o Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 ou Ubuntu 18.04)

    Note

    A partir do SQL Server 2025 (17.x), não há suporte para SLES (SUSE Linux Enterprise Server).

  • Sistema de arquivos XFS para armazenamento do SQL Server, no kernel 4.18 ou versões posteriores do Linux.

  • sistema de arquivos ext4 para armazenamento do SQL Server, no kernel 5.6 ou versões posteriores do Linux.

    Note

    Use o sistema de arquivos XFS para hospedar arquivos de log de transações e dados do SQL Server quando a versão do kernel do Linux for menor que 5.6. A partir do kernel versão 5.6, você pode escolher entre XFS e ext4 com base em seus requisitos específicos.

  • Subsistema de armazenamento e hardware que dá suporte e está configurado para a funcionalidade FUA

Configuração recomendada:

  1. Habilite o sinalizador de rastreamento 3979 como um parâmetro de inicialização.

  2. Use mssql-conf para configurar control.writethrough = 1 e control.alternatewritethrough = 0.

Para quase todas as outras configurações que não atendem às condições anteriores, use a seguinte configuração recomendada:

  1. Habilite o sinalizador de rastreamento 3982 como um parâmetro de inicialização (que é o padrão para o SQL Server no ecossistema do Linux) e verifique se o sinalizador de rastreamento 3979 não está habilitado como um parâmetro de inicialização.

  2. Use mssql-conf para configurar control.writethrough = 1 e control.alternatewritethrough = 1.

Suporte ao FUA para contêineres de SQL Server implantados no Kubernetes

  1. O SQL Server deve usar o armazenamento montado persistente e não overlayfs.

  2. O armazenamento deve usar os sistemas de arquivos XFS ou ext4 e deve dar suporte a FUA (ext4 não dá suporte a FUA no kernel do Linux anterior à versão 5.6). Antes de habilitar essa configuração, trabalhe com o fornecedor de distribuição e armazenamento do Linux para garantir que o sistema operacional e o subsistema de armazenamento ofereçam suporte a opções FUA. No Kubernetes, você pode consultar o tipo de sistema de arquivos usando o seguinte comando, em que <pvc-name> é o seu PersistentVolumeClaim:

    kubectl describe pv <pvc-name>
    

    Na saída, procure o fstype que está definido como XFS.

  3. O nó de trabalho que hospeda os pods do SQL Server deve usar uma distribuição e uma versão do Linux que dá suporte à funcionalidade FUA (começando com o Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 ou Ubuntu 18.04).

Se as condições anteriores forem atendidas, use as seguintes configurações recomendadas de FUA:

  1. Habilite o sinalizador de rastreamento 3979 como um parâmetro de inicialização.

  2. Use mssql-conf para configurar control.writethrough = 1 e control.alternatewritethrough = 0.