Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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
ndctlpara configurar o dispositivo PMEM com Instalar NDCTL. - Use
ndctlpara 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
mmapresulta 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 (
.mdfe.ndf) e do log de transações (.ldf) não usamwritethroughealternatewritethroughpor 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 awritethroughlógica ealternatewritethrough.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 aswritethroughotimizações ealternatewritethrough.
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:
Habilite o sinalizador de rastreamento 3979 como um parâmetro de inicialização.
Use
mssql-confpara configurarcontrol.writethrough = 1econtrol.alternatewritethrough = 0.
Para quase todas as outras configurações que não atendem às condições anteriores, use a seguinte configuração recomendada:
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.
Use
mssql-confpara configurarcontrol.writethrough = 1econtrol.alternatewritethrough = 1.
Suporte ao FUA para contêineres de SQL Server implantados no Kubernetes
O SQL Server deve usar o armazenamento montado persistente e não
overlayfs.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 seuPersistentVolumeClaim:kubectl describe pv <pvc-name>Na saída, procure o
fstypeque está definido como XFS.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:
Habilite o sinalizador de rastreamento 3979 como um parâmetro de inicialização.
Use
mssql-confpara configurarcontrol.writethrough = 1econtrol.alternatewritethrough = 0.