Configurer la mémoire persistante (PMEM) pour SQL Server sur Linux

S’applique à :SQL Server sur Linux

Cet article décrit comment configurer la mémoire persistante (PMEM) pour SQL Server 2019 (15.x) et les versions ultérieures sous Linux.

Aperçu

SQL Server 2019 (15.x) ajoute un support mémoire persistant pour accélérer plusieurs opérations gourmands en stockage.

Avec un système de fichiers sensible au PMEM, la cartographie mémoire (mmap()) donne aux applications en espace utilisateur un accès direct aux données des fichiers. Lorsqu’une carte mémoire est créée pour un fichier, l’application peut émettre des instructions de chargement/stockage qui contournent la couche de stockage.

Cet article vous montre comment configurer la mémoire persistante pour SQL Server sur Linux.

Créer des espaces de noms pour les appareils PMEM

Configurer les appareils

Dans Linux, utilisez l’utilitaire ndctl.

• Installez ndctl pour configurer l’appareil PMEM depuis l'installation de NDCTL.
• Utilisez ndctl pour créer un espace de noms. Les espaces de noms sont entrelacés sur les NVDIMM PMEM et peuvent fournir différents types d’accès d’espace utilisateur aux régions de la mémoire sur l’appareil. fsdax est le mode par défaut et souhaité pour SQL Server.

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

Le fsdax mode stocke les métadonnées par page dans la mémoire système. Cette --map=dev option est recommandée car elle stocke directement les métadonnées dans l’espace de noms. Stocker des métadonnées en mémoire avec --map=mem est expérimental.

Utilisez ndctl pour vérifier l’espace de noms.

Exemple de sortie :

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

Créez et montez un appareil PMEM

Par exemple, avec XFS :

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

Par exemple, avec ext4 :

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

Considérations techniques

• Bloquer l’allocation de 2 Mo pour XFS ou ext4, comme décrit précédemment
• Un mauvais alignement entre l’allocation de bloc et mmap entraîne un basculement silencieux sur 4 Ko
• Les tailles de fichier doivent être un multiple de 2 Mo (modulo 2 Mo)
• Ne désactivez pas les pages transparentes de grande taille (THP), activées par défaut sur la plupart des distributions.

Après avoir configuré ndctl , créé et monté l’appareil, vous pouvez y placer des fichiers de base de données ou créer une nouvelle base de données.

Vous pouvez stocker les fichiers de données SQL Server (.mdf, ) et tempdb les fichiers sur un appareil PMEM en fsdax mode avec la .ndfcommande suivante. N'utilisez pas ce mode pour stocker les fichiers de journal (.ldf) de SQL Server, car le journal de transactions nécessite un stockage fournissant des garanties atomiques sectorielles :

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

Avant de définir l’option de mappage dans la commande précédente, prenez en compte les points suivants :

• Pour de meilleures performances lors de l’accès et de la mise à jour de ces entrées NVDIMM pour cet appareil, utilisez -map=mem
• Si la capacité du NVDIMM est trop grande (supérieure à 512 Go), réglez -map=dev, ce qui affecte le débit d’E/S et réduit les performances

Pour les fichiers journaux SQL Server sur les appareils PMEM, configurez les appareils PMEM pour utiliser la table de traduction sectorieuse/bloc (BTT). Cette configuration fournit l’atomicité sectorielle que les fichiers journaux SQL Server nécessitent pour cette technologie de stockage. Effectuez des validations de performance de charge de travail. Comparez la performance des journaux SQL Server pour votre charge de travail entre cette solution et les meilleurs SSD NVMe, puis sélectionnez celui qui répond le mieux à vos besoins.

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

Désactiver le comportement de vidage forcé

Comme les appareils PMEM sont sécurisés O_DIRECT (E/S directes), vous pouvez désactiver le comportement de vidage forcé.

• Les fichiers de base de données (.mdf et .ndf) et de journal des transactions (.ldf) n’utilisent ni writethrough ni alternatewritethrough par défaut dans SQL Server 2017 (14.x) CU 6 et versions ultérieures, car ils utilisent le comportement de vidage forcé. Le drapeau de trace 3979 désactive le comportement de vidage forcé pour les fichiers journaux de bases de données et transactions, et utilise la writethrough logique et alternatewritethrough .

• D’autres fichiers que SQL Server ouvre avec FILE_FLAG_WRITE_THROUGH, tels que les instantanés de base de données, les instantanés internes pour les vérifications de cohérence de la base de données (DBCC CHECKDB), les fichiers de trace profileur et les fichiers de trace d’événements étendus, utilisent les writethrough optimisations etalternatewritethrough.

Pour plus d’informations sur les modifications introduites dans SQL Server 2017 (14.x) CU 6, voir KB 4131496. Pour plus d'informations sur l'accès forcé à l'unité (FUA) et ses mécanismes internes, consultez FUA internals.

Fonctionnalité du sous-système d’E/S SQL Server et FUA (Forced Unit Access)

Certaines distributions Linux prises en charge implémentent l’accès unitaire forcé (FUA) au niveau du sous-système d’E/S pour garantir la durabilité des données. SQL Server tire parti de cette fonctionnalité pour fournir des performances d’E/S efficaces et fiables pour les charges de travail Linux. Pour plus d’informations sur la prise en charge de FUA dans les distributions Linux et son effet sur SQL Server, consultez SQL Server sur Linux : Accès unitaire forcé (FUA) Internals.

La prise en charge de FUA dans le sous-système d’E/S a été introduite dans SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 et Ubuntu 18.04. Dans SQL Server 2017 (14.x) CU 6 et versions ultérieures, utilisez la configuration suivante pour permettre des E/S hautes performances et efficaces avec FUA dans SQL Server.

Utilisez cette configuration recommandée si les conditions suivantes sont remplies :

• SQL Server 2017 (14.x) CU 6 et versions suivantes

• Distribution et version Linux prenant en charge la fonctionnalité FUA (à partir de Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 ou Ubuntu 18.04)

  Note

  À compter de SQL Server 2025 (17.x), SUSE Linux Enterprise Server (SLES) n’est pas pris en charge.

• Système de fichiers XFS pour le stockage SQL Server, sur le noyau Linux 4.18 ou versions ultérieures.

• système de fichiers ext4 pour le stockage SQL Server, sur le noyau Linux 5.6 ou versions ultérieures.

  Note

  Utilisez le système de fichiers XFS pour héberger des données SQL Server et des fichiers journaux des transactions lorsque la version du noyau Linux est inférieure à 5.6. À compter de la version 5.6 du noyau, vous pouvez choisir entre XFS et ext4 en fonction de vos besoins spécifiques.

• Sous-système de stockage et matériel prenant en charge et configuré pour la fonctionnalité FUA

Configuration recommandée :

1. Activez l’indicateur de trace 3979 en tant que paramètre de démarrage.

2. Permet mssql-conf de configurer control.writethrough = 1 et control.alternatewritethrough = 0.

Pour presque toutes les autres configurations qui ne répondent pas aux conditions précédentes, utilisez la configuration recommandée suivante :

1. Activez l’indicateur de trace 3982 en tant que paramètre de démarrage (qui est la valeur par défaut pour SQL Server dans l’écosystème Linux) et assurez-vous que l’indicateur de trace 3979 n’est pas activé en tant que paramètre de démarrage.

2. Permet mssql-conf de configurer control.writethrough = 1 et control.alternatewritethrough = 1.

Prise en charge de FUA pour les conteneurs SQL Server déployés sur Kubernetes

1. SQL Server doit utiliser le stockage permanent à l’état monté, et pas overlayfs.

2. Le stockage doit utiliser les systèmes de fichiers XFS ou ext4 et doit prendre en charge FUA (ext4 ne prend pas en charge FUA sur le noyau Linux antérieur à la version 5.6). Avant d’activer ce paramètre, collaborez avec votre fournisseur de distribution et de stockage Linux pour vous assurer que le sous-système d’exploitation et le sous-système de stockage prennent en charge les options FUA. Sur Kubernetes, vous pouvez interroger le type de système de fichiers à l’aide de la commande suivante, où <pvc-name> est votre PersistentVolumeClaim :

   kubectl describe pv <pvc-name>
   

   Dans la sortie, recherchez le fstype défini sur XFS.

3. Le nœud Worker hébergeant les pods SQL Server doit utiliser une distribution Linux et une version prenant en charge la fonctionnalité FUA (à partir de Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 ou Ubuntu 18.04).

Si les conditions précédentes sont remplies, utilisez les paramètres FUA recommandés suivants :

1. Activez l’indicateur de trace 3979 en tant que paramètre de démarrage.

2. Permet mssql-conf de configurer control.writethrough = 1 et control.alternatewritethrough = 0.

Contenu connexe

• Qu’est-ce que SQL Server sur Linux ?
• Meilleures pratiques en matière de performances : stockage, noyau, processeur et réseau pour SQL Server sur Linux
• Meilleures pratiques en matière de performances : mémoire de SQL Server sous Linux