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 PMEM (memória persistente) para SQL Server 2019 (15.x) e versões posteriores no Linux.

Visão geral

O SQL Server 2019 (15.x) apresentou muitos recursos na memória que usam memória persistente. Este artigo aborda as etapas necessárias para configurar a memória persistente para SQL Server em Linux.

Observação

O termo capacitação foi introduzido para transmitir o conceito de trabalhar com um sistema de arquivos com reconhecimento de memória persistente. O acesso direto ao sistema de arquivos de aplicativos de espaço do usuário é facilitado usando o mapeamento de memória (mmap()). Quando um mapeamento de memória para um arquivo é criado, o aplicativo pode emitir instruções de carregamento/armazenamento ignorando completamente a pilha de E/S. Isso é considerado um método de acesso de arquivo "capacitado" da perspectiva do aplicativo de extensão de host (que é o código que permite que o SQLPAL interaja com o sistema operacional Windows ou Linux).

Criar namespaces para dispositivos PMEM

Configurar os dispositivos

No Linux, use o utilitário ndctl.

• Instale ndctl para configurar o dispositivo PMEM com a instalação do 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

Escolhemos o modo fsdax e estamos usando a memória do sistema para armazenar os metadados por página. É recomendável usar o --map=dev. Essa opção armazena os metadados diretamente no namespace. O armazenamento de metadados na memória usando --map=mem é experimental no momento.

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 THPs (páginas enormes transparentes) (habilitadas por padrão na maioria dos distribuições)

Depois que o dispositivo for configurado com ndctl, criado e montado, você poderá colocar arquivos de banco de dados nele ou criar um banco de dados.

Você pode armazenar os arquivos de dados do SQL Server (MDFS, NDFS) e arquivos tempdb em um dispositivo PMEM quando configurado com o modo fsdax usando o comando a seguir. Não use para armazenar os arquivos de log do SQL Server (LDFS), pois o log de transações precisa estar no armazenamento que fornece garantias atômicas do 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 obter um melhor desempenho ao acessar e atualizar essas entradas de página do NVDIMM para este dispositivo, é preferível usar -map=mem
• Se a capacidade do NVDIMM for muito grande (maior que 512 GB), defina o –map=dev, o que impactaria a taxa de transferência de E/S e prejudicaria o desempenho

Para arquivos de log do SQL Server em dispositivos PMEM, provisione o(s) dispositivo(s) PMEM para usar o setor/tabela de conversão de blocos (BTT). Isso fornece a atomicidade de setor necessária para arquivos de log do SQL Server para esta tecnologia de dispositivos de armazenamento. Também recomendamos que você execute validações de desempenho da carga de trabalho. Você pode comparar o desempenho do log do SQL Server para sua carga de trabalho entre esta solução e os melhores SSDs NVMe da classe e, em seguida, selecione a solução que melhor atenda às suas necessidades e ofereça melhor desempenho.

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

Desabilitar o comportamento de liberação forçada

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

Observação

Um sistema de armazenamento pode garantir que todas as gravações em cache ou em estágios sejam consideradas seguras e duráveis, garantindo que as gravações emitidas no dispositivo sejam mantidas em um meio que persistirá entre falhas do sistema, redefinições de interface e falhas de energia e o próprio meio é 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. O flag de rastreamento 3979 desabilita o uso do comportamento de descarte forçado para arquivos de log de transações e de banco de dados e usa a lógica writethroughalternatewritethrough.

• Outros arquivos abertos usando FILE_FLAG_WRITE_THROUGH no SQL Server, como instantâneos do banco de dados, instantâneos internos para verificações de consistência de banco de dados (DBCC CHECKDB), arquivos de rastreamento do criador de perfil e arquivos de rastreamento de eventos estendidos, usam as otimizações writethrough 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 os internos do FUA (acesso forçado à unidade), 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 obter mais informações sobre o suporte a FUA em distribuições do Linux e seu efeito no SQL Server, consulte SQL Server no Linux: Acesso forçado à unidade (FUA) Interno.

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)

  Observação

  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.

  Observação

  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.

Conteúdo relacionado

• O que é o SQL Server em Linux?
• Práticas recomendadas de desempenho e diretrizes de configuração para o SQL Server em Linux