Meilleures pratiques en matière de performances et lignes directrices de configuration pour SQL Server sur Linux

S’applique à :SQL Server sur Linux

Cet article présente les meilleures pratiques et suggestions pour optimiser les performances des applications de base de données qui se connectent à SQL Server sur Linux. Ces suggestions sont spécifiques à l’exécution sur la plateforme Linux. Toutes les suggestions de SQL Server normales, telles que la conception d’index, s’appliquent toujours.

Les directives suivantes contiennent des suggestions de configuration de SQL Server et du système d’exploitation Linux. Envisagez d’utiliser ces paramètres de configuration pour bénéficier des meilleures performances pour une installation SQL Server.

• Configuration de stockage recommandée
• Paramètres de noyau et de processeur pour une haute performance
• Configuration de SQL Server

Configuration de stockage recommandée

Le sous-système de stockage qui héberge des données, des journaux de transactions et d’autres fichiers associés (tels que les fichiers de point de contrôle pour OLTP en mémoire) doit être capable de gérer de manière appropriée des charges de travail moyennes et maximales.

Utiliser le sous-système de stockage avec les IOPS, le débit et la redondance appropriés

Dans les environnements locaux, le fournisseur de stockage prend normalement en charge la configuration RAID matérielle appropriée avec le striping sur plusieurs disques pour garantir les IOPS, le débit et la redondance appropriés. Toutefois, cette prise en charge peut différer entre différents fournisseurs de stockage et différentes offres de stockage avec différentes architectures.

Pour SQL Server sur Linux déployé sur des machines virtuelles Azure, envisagez d’utiliser un RAID logiciel pour garantir les exigences appropriées en matière de IOPS et de débit. Lorsque vous configurez SQL Server sur des machines virtuelles Azure avec des considérations de stockage similaires, consultez Configurer le stockage pour SQL Server sur des machines virtuelles Azure.

L’exemple suivant montre comment créer un RAID logiciel dans Linux sur une machine virtuelle Azure. Notez que vous devez utiliser le nombre approprié de disques de données pour le débit et les IOPS requis pour les volumes, selon les exigences relatives aux données, aux journaux de transactions et aux E/S de tempdb. Dans l’exemple suivant, huit disques de données ont été attachés à la machine virtuelle ; quatre pour héberger des fichiers de données, deux pour les journaux de transactions et deux pour la tempdb charge de travail.

Pour localiser les appareils (par exemple /dev/sdc) pour la création de RAID, utilisez la commande lsblk.

# For Data volume, using 4 devices, in RAID 5 configuration with 8KB stripes
mdadm --create --verbose /dev/md0 --level=raid5 --chunk=8K --raid-devices=4 /dev/sdc /dev/sdd /dev/sde /dev/sdf

# For Log volume, using 2 devices in RAID 10 configuration with 64KB stripes
mdadm --create --verbose /dev/md1 --level=raid10 --chunk=64K --raid-devices=2 /dev/sdg /dev/sdh

# For tempdb volume, using 2 devices in RAID 0 configuration with 64KB stripes
mdadm --create --verbose /dev/md2 --level=raid0 --chunk=64K --raid-devices=2 /dev/sdi /dev/sdj

Recommandations relatives à la configuration et au partitionnement de disque

Pour SQL Server, utilisez une configuration RAID. L’unité de bande du système de fichiers déployé (sunit) et la largeur de bande correspondent à la géométrie RAID. Par exemple, voici une configuration basée sur XFS pour un volume de journal.

# Creating a log volume, using 6 devices, in RAID 10 configuration with 64KB stripes
mdadm --create --verbose /dev/md3 --level=raid10 --chunk=64K --raid-devices=6 /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf

mkfs.xfs /dev/md3 -f -L log
meta-data=/dev/md3               isize=512    agcount=32, agsize=18287648 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1
data     =                       bsize=4096   blocks=585204384, imaxpct=5
         =                       sunit=16     swidth=48 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=285744, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Le tableau de journaux est un RAID-10 à six disques avec une bande de 64 Ko. Comme vous pouvez le voir :

• Pour sunit=16 blks, 16 * 4096 taille de bloc = 64 Ko, correspond à la taille de la bande.
• Pour swidth=48 blks, swidth / sunit = 3, ce qui correspond au nombre de lecteurs de données dans le tableau, à l’exception des lecteurs de parité.

Configuration recommandée du système de fichiers

SQL Server prend en charge les systèmes de fichiers ext4 et XFS pour héberger la base de données, les journaux des transactions et d’autres fichiers tels que les fichiers de point de contrôle pour OLTP en mémoire dans SQL Server. Utilisez le système de fichiers XFS pour héberger les données SQL Server et les fichiers journaux des transactions.

Formatez le volume avec le système de fichiers XFS :

mkfs.xfs /dev/md0 -f -L datavolume
mkfs.xfs /dev/md1 -f -L logvolume
mkfs.xfs /dev/md2 -f -L tempdb

Vous pouvez configurer le système de fichiers XFS pour qu’il soit insensible à la casse lors de la création et du formatage du volume XFS. Cette configuration n’est pas fréquemment utilisée dans l’écosystème Linux, mais peut être utilisée pour des raisons de compatibilité.

Par exemple, vous pouvez exécuter la commande suivante. Utilisez -n version=ci pour configurer le système de fichiers XFS afin qu’il soit insensible à la casse.

mkfs.xfs /dev/md0 -f -n version=ci -L datavolume

Système de fichiers de mémoire persistante recommandé

Pour la configuration du système de fichiers sur les appareils de mémoire persistante, définissez l’allocation de bloc pour le système de fichiers sous-jacent sur 2 Mo. Pour plus d’informations, consultez Considérations techniques.

Limitation du nombre de fichiers ouverts

Votre environnement de production pourrait nécessiter plus de connexions que la limite par défaut de fichiers ouverts (1 024). Vous pouvez définir des limites souples et difficiles à 1 048 576. Par exemple, dans RHEL, modifiez le fichier /etc/security/limits.d/99-mssql-server.conf pour qu’il ait les valeurs suivantes :

mssql - nofile 1048576

Note

Ce paramètre ne s’applique pas aux services SQL Server démarrés par systemd. Pour plus d’informations, consultez Comment définir des limites pour les services sous RHEL et systemd.

Désactiver la date et l’heure du dernier accès sur les systèmes de fichiers pour les fichiers journaux et les données SQL Server

Pour vous assurer que les lecteurs attachés au système se remontent automatiquement après un redémarrage, ajoutez-les au /etc/fstab fichier. Utilisez l'UUID (Identificateur universel unique) dans /etc/fstab pour faire référence au lecteur, plutôt que simplement le nom de l'appareil, comme /dev/sdc1.

Utilisez l'attribut noatime avec tout système de fichiers qui stocke les données et les fichiers journaux SQL Server. Reportez-vous à la documentation Linux pour savoir comment définir cet attribut. L’exemple suivant montre comment activer l’option noatime d’un volume monté dans une machine virtuelle Azure.

L’entrée du point de montage dans /etc/fstab :

UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" /data1 xfs rw,attr2,noatime 0 0

Dans l’exemple précédent, l’UUID représente l’appareil que vous pouvez trouver à l’aide de la commande blkid.

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

Certaines versions des distributions Linux prises en charge fournissent une prise en charge de la fonctionnalité du sous-système d’E/S FUA, qui permet d’assurer la durabilité des données. SQL Server utilise la fonctionnalité FUA pour fournir des E/S hautement efficaces et fiables pour la charge de travail SQL Server. Pour plus d’informations sur la prise en charge de FUA par la distribution Linux et son effet sur SQL Server, consultez SQL Server sur Linux : éléments internes d’accès d’unité forcé (FUA).

SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 et Ubuntu 18.04 ont introduit la prise en charge de la fonctionnalité FUA dans le sous-système d’E/S. Si vous utilisez SQL Server 2017 (14.x) CU 6 et des versions ultérieures, vous devez utiliser la configuration suivante pour assurer l’implémentation d’E/S efficace et performante avec FUA par SQL Server.

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

• SQL Server 2017 (14.x) CU 6 et versions ultérieures

• Distribution Linux et 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)

• 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

  Vous devez utiliser 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/ou matériel prenant en charge la fonctionnalité FUA et configuré pour celle-ci

Configuration recommandée :

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

2. Utilisez mssql-conf pour configurer control.writethrough = 1 et control.alternatewritethrough = 0.

Pour presque toutes les autres configurations qui ne respectent pas les conditions précédentes, la configuration recommandée est la 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. Utilisez mssql-conf pour configurer control.writethrough = 1 et control.alternatewritethrough = 1.

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

1. SQL Server doit utiliser un stockage monté persistant, et non 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, vous devez vous assurer auprès de votre fournisseur de distribution et de stockage Linux que le système d’exploitation et le sous-système de stockage prennent bien en charge les options FUA. Sur Kubernetes, vous pouvez interroger le type de système de fichiers avec la commande suivante, où <pvc-name> est votre PersistentVolumeClaim :

   kubectl describe pv <pvc-name>
   

   Dans la sortie, recherchez le fstype qui est 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, vous pouvez utiliser les paramètres FUA recommandés suivants.

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

2. Utilisez mssql-conf pour configurer control.writethrough = 1 et control.alternatewritethrough = 0.

Paramètres de noyau et de processeur pour une haute performance

La section suivante décrit les paramètres de système d’exploitation Linux recommandés en rapport avec la haute performance et le débit d’une installation SQL Server. Reportez-vous à la documentation sur la distribution Linux pour consulter le processus de configuration de ces paramètres. Vous pouvez utiliser TuneD comme décrit pour configurer de nombreuses configurations de processeurs et de noyaux, présentées dans la section suivante.

Utiliser TuneD pour configurer les paramètres de noyau

Pour les utilisateurs de Red Hat Enterprise Linux (RHEL), le profil de performances de débit TuneD configure automatiquement certains paramètres du noyau et CPU (à l’exception des C-States). À compter de RHEL 8.0, un profil TuneD nommé mssql a été co-développé avec Red Hat et offre des optimisations des performances Linux plus précises pour les charges de travail SQL Server. Ce profil inclut le profil débit-performance RHEL. Vous trouverez ses définitions dans cet article, ainsi que d’autres distributions Linux et versions de RHEL sans ce profil.

Pour SUSE Linux Enterprise Server 12 SP5, Ubuntu 18.04 et Red Hat Enterprise Linux 7.x, vous pouvez installer manuellement le tuned package. Utilisez-le pour créer et configurer le mssql profil comme décrit dans la section suivante.

Paramètres Linux proposés avec un profil TuneD mssql

L’exemple suivant présente une configuration TuneD pour SQL Server sur Linux.

[main]
summary=Optimize for Microsoft SQL Server
include=throughput-performance

[cpu]
force_latency=5

[sysctl]
vm.swappiness = 1
vm.dirty_background_ratio = 3
vm.dirty_ratio = 80
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 100
vm.transparent_hugepages=always
# For multi-instance SQL deployments, use
# vm.transparent_hugepages=madvise
vm.max_map_count=1600000
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
kernel.numa_balancing=0

Si vous utilisez des distributions Linux avec des versions de noyau postérieures à la 4.18, ajoutez le caractère de commentaire devant les options suivantes comme indiqué. Dans le cas contraire, retirez le caractère de commentaire des options suivantes si vous utilisez des distributions avec des versions de noyau antérieures à la 4.18.

# kernel.sched_latency_ns = 60000000
# kernel.sched_migration_cost_ns = 500000
# kernel.sched_min_granularity_ns = 15000000
# kernel.sched_wakeup_granularity_ns = 2000000

Pour activer ce profil TuneD, enregistrez ces définitions dans un fichier tuned.conf, dans le dossier /usr/lib/tuned/mssql, et activez le profil en utilisant les commandes suivantes :

chmod +x /usr/lib/tuned/mssql/tuned.conf
tuned-adm profile mssql

Vérifiez que le profil est actif, avec la commande suivante :

tuned-adm active

Ou :

tuned-adm list

Recommandation relative aux paramètres de processeur

La table suivante fournit des suggestions pour les paramètres de l’UC :

Setting	Valeur	Plus d’informations
Gouverneur de fréquence de l’UC	performances	Consultez la commande cpupower
ENERGY_PERF_BIAS	performances	Consultez la commande x86_energy_perf_policy
min_perf_pct	100	Consultez votre documentation sur l’état P Intel
États C	C1 uniquement	Consultez la documentation Linux ou de votre système pour savoir comment garantir que les états C sont définis sur C1 uniquement

Lorsque vous utilisez TuneD comme décrit, il configure automatiquement le gouverneur de fréquence du processeur, ainsi que les paramètres ENERGY_PERF_BIASmin_perf_pct. Il utilise le profil débit-performance comme base pour le profil mssql. Vous devez configurer manuellement le paramètre C-States en fonction de la documentation fournie par Linux ou votre serveur de distribution système.

Recommandations relatives aux paramètres de disque

La table suivante fournit des suggestions pour les paramètres du disque :

Setting	Valeur	Plus d’informations
Disque readahead	4096	Consultez la commande blockdev
Paramètres sysctl	kernel.sched_min_granularity_ns = 15000000 kernel.sched_wakeup_granularity_ns = 2000000 vm.dirty_ratio = 80 vm.dirty_background_ratio = 3 vm.swappiness = 1	Consultez la commande sysctl

Descriptif

• vm.swappiness: ce paramètre contrôle l’épaisseur relative donnée pour échanger la mémoire du processus d’exécution par rapport au cache du système de fichiers. La valeur par défaut de ce paramètre est 60, ce qui indique l’échange des pages mémoire du processus d’exécution par rapport à la suppression des pages de cache du système de fichiers à un ratio de 60:140. La définition de la valeur 1 indique une préférence forte pour conserver la mémoire du processus d’exécution en mémoire physique au détriment du cache du système de fichiers. Étant donné que SQL Server utilise le pool de mémoire tampon en tant que cache de pages de données et préfère nettement écrire directement sur le matériel physique en contournant le cache du système de fichiers pour une récupération fiable, une configuration d’échange agressive peut être bénéfique pour un SQL Server hautement performant et entièrement dédié.

  Vous trouverez des informations supplémentaires dans Documentation pour /proc/sys/vm/ - #swappiness

• vm.dirty_* : les accès en écriture aux fichiers SQL Server ne sont pas mis en cache pour répondre aux exigences d’intégrité des données. Ces paramètres permettent de bonnes performances d’écriture asynchrone et réduisent l’impact des E/S de stockage des écritures de mise en cache Linux en permettant une mise en cache suffisamment importante pendant la limitation du vidage.

• kernel.sched_*: Ces valeurs de paramètre représentent la recommandation actuelle pour ajuster l’algorithme CFS (Complete Fair Planning) dans le noyau Linux. Ils améliorent le débit des appels d’E/S de réseau et de stockage en ce qui concerne la préemption et la reprise des threads entre processus.

L’utilisation du profil TuneD mssql configure les paramètres vm.swappiness, vm.dirty_* et kernel.sched_*. Vous devez configurer manuellement le paramètre de disque readahead à l’aide de la blockdev commande pour chaque appareil.

Définition du noyau équilibrage automatique NUMA pour les systèmes NUMA multinode

Si vous installez SQL Server sur un système NUMA multinode, le paramètre de noyau suivant kernel.numa_balancing est activé par défaut. Pour permettre à SQL Server d’opérer au maximum sur un système NUMA, désactivez l’équilibrage NUMA automatique sur un système NUMA multinode :

sysctl -w kernel.numa_balancing=0

L’utilisation du profil TuneD mssql configure l’option kernel.numa_balancing.

Paramètres de noyau pour l’espace d’adressage virtuel

La valeur par défaut de vm.max_map_count (65536) pourrait ne pas être suffisamment élevée pour une installation SQL Server. Par conséquent, remplacez la valeur de vm.max_map_count par au moins 262144 pour un déploiement SQL Server et reportez-vous à la section Paramètres Linux proposés avec un profil mssql TuneD pour affiner encore ces paramètres de noyau. La valeur maximale pour vm.max_map_count est 2147483647.

sysctl -w vm.max_map_count=1600000

L’utilisation du profil TuneD mssql configure l’option vm.max_map_count.

Laissez les pages volumineuses transparentes (THP) activées

La plupart des installations Linux ont cette option par défaut. Pour l’expérience de performances la plus cohérente, laissez cette option de configuration activée. Toutefois, s’il existe une activité de pagination de mémoire élevée dans les déploiements SQL Server avec plusieurs instances ou l’exécution de SQL Server avec d’autres applications exigeantes en mémoire sur le serveur, testez les performances de votre application après l’exécution de la commande suivante :

echo madvise > /sys/kernel/mm/transparent_hugepage/enabled

Vous pouvez aussi modifier le profil TuneD mssql avec la ligne :

vm.transparent_hugepages=madvise

Vérifiez que le mssql profil est actif après la modification :

tuned-adm off
tuned-adm profile mssql

L’utilisation du profil TuneD mssql configure l’option transparent_hugepage.

Recommandations relatives aux paramètres réseau

Outre les recommandations relatives au stockage et au processeur, vous disposez également de recommandations spécifiques au réseau. Les recommandations suivantes sont répertoriées pour référence. Tous les paramètres des exemples suivants ne sont pas disponibles sur différentes cartes réseau. Pour obtenir des conseils sur chacune de ces options, contactez les fournisseurs de cartes réseau. Testez et configurez ces paramètres sur des environnements de développement avant de les appliquer à des environnements de production. Les options suivantes sont expliquées avec des exemples, et les commandes utilisées sont propres à un type et à un fournisseur de carte réseau.

1. Configuration de la taille de la mémoire tampon du port réseau. Dans l’exemple, la carte réseau est nommée eth0, qui est une carte réseau basée sur Intel. Pour les cartes réseau Intel, la taille de la mémoire tampon recommandée est de 4 Ko (4096). Vérifiez les valeurs maximales prédéfinies, puis effectuez la configuration à l’aide de l’exemple suivant :

   Vérifiez les maximums prédéfinis avec la commande suivante. Remplacez eth0 par le nom de votre carte d'interface réseau :

   ethtool -g eth0
   

   Définissez la taille des tampons rx (réception) et tx (transmission) sur 4 Ko :

   ethtool -G eth0 rx 4096 tx 4096
   

   Vérifiez que la valeur est correctement configurée :

   ethtool -g eth0
   

2. Activer les trames Jumbo. Avant d’activer les trames Jumbo, vérifiez que tous les commutateurs réseau, routeurs et autres éléments essentiels dans le chemin du paquet réseau entre les clients et SQL Server prennent en charge les trames Jumbo. Ce n'est qu'en activant les jumbo frames que l'on peut améliorer les performances. Une fois les trames jumbo activées, connectez-vous à SQL Server et remplacez la taille du paquet réseau par 8060 à l’aide sp_configurede l’exemple suivant :

   # command to set jumbo frame to 9014 for a Intel NIC named eth0 is
   ifconfig eth0 mtu 9014
   # verify the setting using the command:
   ip addr | grep 9014
   

   EXECUTE sp_configure 'network packet size', '8060';
   GO
   
   RECONFIGURE WITH OVERRIDE;
   GO
   

3. Par défaut, le port est défini pour la coalescence IRQ RX/TX adaptative, ce qui signifie que la remise d'interruptions est ajustée afin d'améliorer la latence lorsque le taux de paquets est faible et d'améliorer le débit lorsque le taux de paquets est élevé. Ce paramètre peut ne pas être disponible sur votre infrastructure réseau. Vérifiez donc l’infrastructure réseau existante et vérifiez que ce paramètre est pris en charge. L’exemple est destiné à la carte réseau nommée eth0, qui est une carte réseau Intel :

   1. Définissez le port pour la coalescence adaptative des IRQ RX/TX :

      ethtool -C eth0 adaptive-rx on
      ethtool -C eth0 adaptive-tx on
      

   2. Confirmez le paramètre :

      ethtool -c eth0
      

   Note

   Pour un comportement prévisible dans des environnements hautes performances, comme les environnements d’évaluation, désactivez la fusion rx/TX adaptative IRQ, puis définissez spécifiquement la fusion d’interruption RX/TX. Consultez les exemples de commandes pour désactiver la fusion des IRQ RX/TX, puis définissez spécifiquement les valeurs :

   Désactivez la coalescence adaptative des IRQ RX/TX :

   ethtool -C eth0 adaptive-rx off
   ethtool -C eth0 adaptive-tx off
   

   Confirmez la modification :

   ethtool -c eth0
   

   Définir les paramètres rx-usecs et irq. rx-usecs spécifie le nombre de microsecondes après la réception d’au moins un paquet avant de générer une interruption. Le paramètre irq définit les délais correspondants de mise à jour de l'état lorsque l'interruption est désactivée. Pour les cartes réseau Intel, vous pouvez utiliser les paramètres suivants :

   ethtool -C eth0 rx-usecs 100 tx-frames-irq 512
   

   Confirmez la modification :

   ethtool -c eth0
   

4. Activez la mise à l’échelle côté réception (RSS) et, par défaut, combinez le côté RX et TX des files d’attente RSS. Il existe des scénarios spécifiques, lors de l’utilisation du support Microsoft, où la désactivation de RSS améliore également les performances. Testez ce paramètre dans les environnements de test avant de l’appliquer à des environnements de production. L’exemple suivant s’applique aux cartes réseau Intel.

   Obtenez les valeurs maximales prédéfinies :

   ethtool -l eth0
   

   Combinez les files d’attente avec la valeur indiquée dans la valeur maximale « combinée » prédéfinie. Dans cet exemple, la valeur est définie sur 8 :

   ethtool -L eth0 combined 8
   

   Vérifier le paramètre :

   ethtool -l eth0
   

5. Utiliser l’affinité IRQ du port de carte réseau. Pour obtenir les performances attendues en ajustant l'affinité IRQ, tenez compte de quelques paramètres importants tels que la gestion par Linux de la topologie du serveur, la pile du pilote NIC, les paramètres par défaut et le paramètre irqbalance. Les optimisations des paramètres d'affinités IRQ du port de la carte réseau sont effectuées en fonction de la connaissance de la topologie du serveur, de la désactivation de irqbalance, et de l'utilisation des paramètres spécifiques au fournisseur de la carte réseau.

   Cet exemple d’infrastructure réseau spécifique à Mellanox vous aide à comprendre la configuration. Pour plus d’informations, et pour télécharger les outils mlnx Mellanox, consultez ​​Outils de réglage des performances pour les adaptateurs réseau Mellanox. Les commandes varient en fonction de l’environnement. Pour plus d’informations, contactez le fournisseur de la carte réseau.

   Désactiver irqbalance, ou obtenir un instantané des paramètres IRQ, puis forcez l'arrêt du démon :

   systemctl disable irqbalance.service
   

   Ou :

   irqbalance --oneshot
   

   S'assurer que common_irq_affinity.sh est exécutable :

   chmod +x common_irq_affinity.sh
   

   Afficher l’affinité des IRQ pour le port de carte d'interface réseau Mellanox (par exemple, eth0) :

   ./show_irq_affinity.sh eth0
   

   Optimiser les performances de débit avec un outil Mellanox :

   ./mlnx_tune -p HIGH_THROUGHPUT
   

   Définir l’affinité matérielle sur le nœud NUMA qui héberge physiquement la carte d'interface réseau et son port :

   ./set_irq_affinity_bynode.sh `\cat /sys/class/net/eth0/device/numa_node` eth0
   

   Vérifier l’affinité des IRQ :

   ./show_irq_affinity.sh eth0
   

   Ajouter des optimisations de coalescence des IRQ

   ethtool -C eth0 adaptive-rx off
   ethtool -C eth0 adaptive-tx off
   ethtool -C eth0  rx-usecs 750 tx-frames-irq 2048
   

   Vérifiez les paramètres :

   ethtool -c eth0
   

6. Après avoir apporté les modifications précédentes, vérifiez la vitesse de la carte réseau pour vous assurer qu’elle correspond à vos attentes à l’aide de la commande suivante :

   ethtool eth0 | grep -i Speed
   

Configuration avancée du noyau et du système d’exploitation

• Pour obtenir les meilleures performances d’E/S de stockage, utilisez la planification multiqueue Linux pour les appareils de bloc. Cette méthode de planification permet aux performances de la couche de blocs de s’adapter correctement avec des disques SSD (SSD) rapides et des systèmes multicœurs. Consultez la documentation pour voir si votre distribution Linux l’active par défaut. Dans la plupart des autres cas, vous pouvez démarrer le noyau avec scsi_mod.use_blk_mq=y pour l’activer. La documentation de votre distribution Linux peut avoir des conseils supplémentaires sur ce paramètre. Ce paramètre est cohérent avec le noyau Linux en amont.

• Étant donné que l'E/S multipath est souvent utilisée pour les déploiements SQL Server, configurez la cible multiqueue du device mapper (DM) pour utiliser l'infrastructure blk-mq, en activant l'option de démarrage du noyau dm_mod.use_blk_mq=y. La valeur par défaut est n (désactivé). Ce paramètre réduit la surcharge de verrouillage au niveau de la couche DM lorsque les appareils SCSI sous-jacents utilisent blk-mq. Pour plus d’informations sur la configuration Multipath I/O, consultez la documentation de votre distribution Linux.

Configurer un fichier d’échange

Vérifiez que vous disposez d’un fichier d’échange correctement configuré pour éviter les problèmes de mémoire insuffisante. Consultez la documentation Linux pour savoir comment créer et dimensionner correctement un fichier d’échange.

Machines virtuelles et mémoire dynamique

Si vous exécutez SQL Server sur Linux sur une machine virtuelle, assurez-vous de sélectionner des options pour corriger la quantité de mémoire réservée pour la machine virtuelle. N’utilisez pas de fonctionnalités comme Mémoire dynamique Hyper-V.

Configuration de SQL Server

Effectuez les tâches de configuration suivantes après avoir installé SQL Server sur Linux pour obtenir les meilleures performances pour votre application.

Meilleures pratiques

Utiliser PROCESS AFFINITY pour le nœud et/ou les UC

Utilisez ALTER SERVER CONFIGURATION pour définir PROCESS AFFINITY pour tous les NUMANODE et processeurs que vous utilisez pour SQL Server (généralement pour tous les NŒUDS et processeurs) sur un système d’exploitation Linux. L’affinité du processus permet de conserver un comportement de planification Linux et SQL efficace. L’utilisation de l’option NUMANODE est la méthode la plus simple. Utilisez PROCESS AFFINITY même si vous n’avez qu’un seul nœud NUMA sur votre ordinateur. Pour plus d’informations sur la manière de définir PROCESS AFFINITY, consultez l’article ALTER SERVER CONFIGURATION.

Configurer plusieurs fichiers de données tempdb

Étant donné qu’une installation SQL Server sur Linux ne propose pas d’options de configuration de plusieurs fichiers tempdb, nous vous recommandons de considérer la création de plusieurs fichiers de données tempdb après l’installation. Pour plus d’informations, reportez-vous aux instructions de l’article Suggestions pour réduire la contention d’allocation dans la base de données tempdb SQL Server.

Configuration avancée

Les suggestions suivantes sont des paramètres de configuration facultatifs que vous pouvez choisir d’effectuer après l’installation de SQL Server sur Linux. Ces choix sont basés sur les exigences de votre charge de travail et la configuration de votre système d’exploitation Linux.

Définir une limite de mémoire avec mssql-conf

Pour vous assurer qu’il existe suffisamment de mémoire physique libre pour le système d’exploitation Linux, le processus SQL Server utilise uniquement 80% de la RAM physique par défaut. Pour certains systèmes avec de grandes quantités de RAM physique, 20% peuvent être un nombre significatif.

Par exemple, sur un système avec 1 To de RAM, le paramètre par défaut laisse environ 200 Go de RAM inutilisée. Dans ce cas, vous souhaiterez peut-être configurer la limite de la mémoire sur une valeur plus élevée. Vous pouvez ajuster cette valeur avec l’outil mssql-conf . Pour plus d’informations, consultez le paramètre memory.memorylimitmb qui contrôle la mémoire visible par SQL Server (en unités de Mo).

Note

Vous pouvez également configurer une limite de mémoire à l’aide de la variable d’environnement MSSQL_MEMORY_LIMIT_MB . Cette méthode est couramment utilisée lors du déploiement de conteneurs, ou lors de l’automatisation des déploiements sql Server ou basés sur des packages. La MSSQL_MEMORY_LIMIT_MB variable d’environnement est prioritaire sur le memory.memorylimitmb paramètre.

Lorsque vous modifiez ce paramètre, veillez à ne pas définir cette valeur trop élevée. Si vous ne laissez pas assez de mémoire, vous pouvez rencontrer des problèmes avec le système d’exploitation Linux et d’autres applications Linux.

Configurer des limites de mémoire avec le groupe de contrôle (cgroup) v2

À compter de SQL Server 2025 (17.x) et SQL Server 2022 (16.x) CU 20, SQL Server détecte et respecte les contraintes de groupe de contrôle (cgroup) v2, améliorant ainsi la stabilité des performances et l’isolation des ressources dans les environnements Docker, Kubernetes et OpenShift. Les groupes de contrôles permettent un contrôle précis dans le noyau Linux sur des ressources système telles que le processeur et la mémoire.

Avec la prise en charge de cgroup v2, SQL Server atténue les erreurs de mémoire insuffisante (OOM) précédemment observées dans les déploiements conteneurisés, en particulier sur les clusters Kubernetes (par exemple, AKS v1.25+), où les limites de mémoire définies dans les spécifications de conteneur n’ont pas été appliquées.

Vérifier la version de cgroup

stat -fc %T /sys/fs/cgroup

Les résultats sont les suivants :

Résultat	Descriptif
cgroup2fs	Vous utilisez cgroup v2
cgroup	Vous utilisez cgroup v1

Basculer vers cgroup v2

Le chemin le plus simple consiste à choisir une distribution qui prend en charge cgroup v2 de manière native.

Si vous devez basculer manuellement, ajoutez la ligne suivante à votre configuration GRUB :

systemd.unified_cgroup_hierarchy=1

Exécutez ensuite la commande suivante pour mettre à jour GRUB :

sudo update-grub

Pour plus d’informations, consultez les ressources suivantes :

• Démarrage rapide : Déployer un conteneur Linux SQL Server sur Kubernetes à l’aide de graphiques Helm
• Documentation de cgroup v2 du noyau Linux
• Groupe de contrôles v2

Instructions pour définir des limites de mémoire

Lorsque vous définissez des limites de mémoire pour SQL Server sur Linux, tenez compte des instructions suivantes :

• Permet cgroup de limiter la mémoire globale disponible pour le conteneur. Ce paramètre établit la limite supérieure pour tous les processus à l’intérieur du conteneur.

• La limite de mémoire (définie par ou par memorylimitmb la MSSQL_MEMORY_LIMIT_MB variable d’environnement) contrôle la mémoire totale que SQL Server sur Linux peut allouer sur tous ses composants, tels que le pool de mémoires tampons, SQLPAL, SQL Server Agent, LibOS, PolyBase, Full-Text Search et tout autre processus chargé dans SQL Server sur Linux.

• La MSSQL_MEMORY_LIMIT_MB variable d’environnement est prioritaire sur memorylimitmb définie dans mssql.conf.

• memorylimitmb ne peut pas dépasser la mémoire physique réelle du système hôte.

• Définissez memorylimitmb une mémoire inférieure à la mémoire du système hôte et à la limite du groupe cgroup (le cas échéant), pour vous assurer qu’il existe suffisamment de mémoire physique libre pour le système d’exploitation Linux. Si vous ne définissez memorylimitmbpas explicitement, SQL Server utilise 80% de la valeur inférieure entre la mémoire système totale et la limite du groupe cgroup (le cas échéant).

• L’option de configuration de serveur max_server_memory limite uniquement la taille du pool de mémoires tampons SQL Server et ne régit pas l’utilisation globale de la mémoire pour SQL Server sur Linux. Définissez toujours cette valeur inférieure à memorylimitmb pour garantir qu'il reste suffisamment de mémoire pour d'autres composants, tels que SQLPAL, SQL Server Agent, LibOS, PolyBase, Full-Text Search et tout autre processus chargé dans SQL Server sur Linux.

Contenu associé

• Procédure pas à pas pour les fonctionnalités relatives aux performances de SQL Server sur Linux
• Qu’est-ce que SQL Server sur Linux ?