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

  • Artigo

Aplica-se a: SQL Server – 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. Você pode encontrá-lo aqui.
  • 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 a alocação de 2 MB para XFS/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 Sinalizador de Rastreamento 3979 desabilita o uso do comportamento de liberação forçada para arquivos de log do banco de dados e transações e usa a lógica writethrough e alternatewritethrough.

  • 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 versões de distribuições do Linux compatíveis fornecem suporte à funcionalidade de subsistema de E/S do FUA, que oferece durabilidade de dados. O SQL Server usa o recurso FUA para fornecer E/S altamente eficiente e confiável para as cargas de trabalho do SQL Server. 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 SUSE Linux Enterprise Server 12 SP5, o Red Hat Enterprise Linux 8.0 e o Ubuntu 18.04 apresentaram o suporte ao recurso FUA no subsistema de E/S. Se você está usando o SQL Server 2017 (14.x) CU 6 e versões posteriores, use a configuração a seguir para obter uma implementação de E/S eficiente e de alto desempenho com o FUA pelo SQL Server.

Use esta configuração recomendada se as condições a seguir 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)

  • Sistema de arquivos XFS para armazenamento de SQL Server

  • Hardware e/ou subsistema de armazenamento que dá suporte e está configurado para o recurso FUA

Configuração recomendada:

  1. Habilitar 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, a configuração recomendada é a seguinte:

  1. Habilite o Sinalizador de Rastreamento 3982 como um parâmetro de inicialização (que é o padrão para o SQL Server no ecossistema Linux) e verifique se o Sinalizador de Rastreamento 3979 não está habilitado como 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 o sistema de arquivos XFS e deve dar suporte ao FUA. Antes de habilitar essa configuração, você deve trabalhar com o fornecedor de armazenamento e distribuição 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 estar usando uma distribuição e versão do Linux que ofereça suporte ao recurso 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 acima forem atendidas, você poderá usar as configurações do FUA recomendadas a seguir.

  1. Habilitar 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