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

Article
04/19/2024

S’applique à : SQL Server - 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. Vous pouvez utiliser ces paramètres de configuration du système d’exploitation Linux pour bénéficier de meilleures performances lors de votre installation de 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 E/S par seconde, le débit et la redondance appropriés

Normalement, dans des environnements locaux, le fournisseur de stockage prend en charge la configuration RAID matérielle appropriée avec agrégation par bandes sur plusieurs disques pour garantir des E/S par seconde, un débit et une redondance appropriés. Toutefois, cela peut varier selon les fournisseurs de stockage et les offres de stockage aux architectures variées.

Pour un déploiement de SQL Server sur Linux sur des machines virtuelles Azure, envisagez d’utiliser un RAID logiciel pour répondre aux besoins d’E/S par seconde et de débit. Lorsque vous configurez des SQL Server sur des machines virtuelles Azure avec des considérations de stockage similaires, consultez Configuration du stockage pour les machines virtuelles SQL Server.

L'exemple suivant montre comment créer un RAID logiciel sous Linux sur des machines virtuelles Azure. Notez que vous devez utiliser le nombre approprié de disques de données pour le débit et les E/S par seconde 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 Azure : 4 pour héberger les fichiers de données, 2 pour les journaux des transactions et 2 pour la charge de travail tempdb.

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, vous devez utiliser une configuration RAID. L’unité de bande déployée (sunit) et la largeur de bande du système de fichiers devraient correspondre à la géométrie RAID. Voici un exemple basé 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 une configuration RAID-10 à 6 lecteurs 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é.

suggestion de configuration 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 des fichiers supplémentaires, tels que les fichiers de point de contrôle pour OLTP en mémoire dans SQL Server. Microsoft recommande d’utiliser le système de fichiers XFS pour héberger les données et journaux de transactions SQL Server.

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

Il est possible de configurer le système de fichiers XFS pour qu’il ne prenne pas en compte la casse lors de la création et de la mise en forme du volume XFS. Ceci n’est pas une configuration fréquente de l’écosystème Linux, mais elle peut être utilisée pour des raisons de compatibilité.

Par exemple, vous pouvez exécuter la commande suivante. -n version=ci est utilisé pour configurer le système de fichiers XFS afin qu’il ne prenne pas en compte 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 à mémoire persistante, l’allocation de blocs pour le système de fichiers sous-jacent doit être de 2 Mo. Pour plus d’informations sur cet article, consultez l’article Considérations techniques.

Limitation du nombre de fichiers ouverts

Votre environnement de production peut nécessiter plus de connexions que la limite par défaut de fichiers ouverts de 1 024. Vous pouvez définir des limites souples et strictes de 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

Remarque

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 dans RHEL et systemd.

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

Pour vous assurer que les lecteurs attachés au système sont remontés automatiquement après un redémarrage, ajoutez-les au fichier /etc/fstab. Vous devez également utiliser l’UUID (identificateur unique universel) dans /etc/fstab pour faire référence au lecteur plutôt que d’utiliser uniquement le nom de l’appareil (tel que /dev/sdc1).

Utilisez l'attribut noatime avec n’importe quel système de fichiers stockant les données et les fichiers journaux SQL Server. Reportez-vous à la documentation Linux pour savoir comment définir cet attribut. Vous trouverez ci-dessous un exemple illustrant comment activer l’option noatime pour 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 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)
Système de fichiers XFS pour le stockage SQL Server
Sous-système de stockage et/ou matériel prenant en charge la fonctionnalité FUA et configurés pour celle-ci

Configuration recommandée :

Activez l’indicateur de trace 3979 en tant que paramètre de démarrage.
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 :

Activez l’indicateur de trace 3982 comme paramètre de démarrage (par défaut pour SQL Server dans l’écosystème Linux), et veillez à ce que l’indicateur de trace 3979 ne soit pas activé en tant que paramètre de démarrage.
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

SQL Server doit utiliser le stockage permanent à l’état monté, et pas overlayfs.
Le stockage doit utiliser le système de fichiers XFS et doit prendre en charge FUA. 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 à 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.
Le nœud de travail 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 ci-dessus sont remplies, vous pouvez utiliser les paramètres recommandés FUA suivants.

Activez l’indicateur de trace 3979 en tant que paramètre de démarrage.
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 débit-performance TuneD configure automatiquement certains paramètres de noyau et de processeur (à l’exception des états C). À 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 de performance de débit de RHEL, et nous présentons ses définitions dans cet article pour que vous puissiez l'examiner avec d'autres distributions Linux et d'autres versions de RHEL qui n'ont pas ce profil.

Pour SUSE Linux Enterprise Server 12 SP5, Ubuntu 18.04 et Red Hat Enterprise Linux 7.x, le package tuned peut être installé manuellement. Il peut être utilisé pour créer et configurer le profil mssql comme décrit dans la section qui suit.

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

L’exemple suivant permet 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 supérieures à 4.18, commentez les options suivantes comme indiqué : dans le cas contraire, supprimez les marques de commentaire suivantes.

# 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 sous 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 :

Paramètre	Valeur	Informations complémentaires
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

L’utilisation de TuneD comme décrit précédemment configure automatiquement les paramètres du gouverneur de fréquence de processeur, ENERGY_PERF_BIAS et les paramètres min_perf_pct, de façon appropriée, car le profil débit-performance est utilisé comme base pour le profil mssql. Le paramètre des états C doit être configuré manuellement conformément à la documentation fournie par Linux ou le distributeur du système.

Recommandations relatives aux paramètres de disque

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

Paramètre	Valeur	Informations complémentaires
Disk `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

Description

vm.swappiness : Ce paramètre contrôle le poids relatif donné à l’échange de la mémoire du processus de runtime par rapport au cache du système de fichiers. La valeur par défaut de ce paramètre est 60, ce qui signifie que le ratio de l’échange des pages de mémoire du processus de runtime par rapport à la suppression des pages de cache du système de fichiers est de 60:140. La définition de la valeur 1 indique une préférence forte pour la conservation de la mémoire du processus de runtime dans la mémoire physique au détriment du cache du système de fichiers. Étant donné que SQL Server utilise un pool de mémoires tampons comme cache de pages de données et qu’il préfère fortement écrire sur du matériel physique, contournant ainsi le cache du système de fichiers pour garantir une récupération fiable, une configuration d’échange agressive peut être bénéfique pour un serveur SQL Server dédié et hautement performant. 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, tout en offrant une mise en cache suffisante pendant la limitation du vidage.
kernel.sched_* : ces valeurs de paramètre correspondent à la suggestion actuelle pour la modification de l’algorithme CFS (Completely Fair Scheduling) dans le noyau Linux, afin d’améliorer le débit des appels d’E/S de réseau et de stockage en ce qui concerne la préemption entre processus et la reprise des threads.

L’utilisation du profil TuneD mssql configure les paramètres vm.swappiness, vm.dirty_* et kernel.sched_*. La configuration de disk readahead à l’aide de la commande blockdev s’effectue appareil par appareil et doit être effectuée manuellement.

Paramètre de noyau d’équilibrage NUMA automatique pour les systèmes NUMA à plusieurs nœuds

Si vous installez SQL Server sur un système NUMA à plusieurs nœuds, le paramètre de noyau kernel.numa_balancing suivant est activé par défaut. Pour permettre à SQL Server de fonctionner avec un niveau d'efficacité maximal sur un système NUMA, désactivez l’équilibrage NUMA automatique sur un système NUMA à plusieurs nœuds :

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

Le paramètre par défaut de vm.max_map_count (65536) peut 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 pourvm.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

Cette option doit être activée par défaut pour la plupart des installations Linux. Nous vous recommandons d’utiliser les performances les plus cohérentes pour garder cette option de configuration activée. Toutefois, en cas d’activité de pagination sollicitant une grande quantité de mémoire (par exemple, dans le cadre de déploiements SQL Server avec plusieurs instances ou d’une exécution de SQL Server avec d’autres applications nécessitant une grande quantité de mémoire sur le serveur), nous vous suggérons de tester les performances de vos applications 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

Et rendre le profil mssql 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

À l’instar des recommandations en matière de stockage et de processeur, il existe des recommandations spécifiques liées au réseau. Celles-ci sont listées ci-dessous 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.

Configuration de la taille de la mémoire tampon du port réseau. Dans l’exemple ci-dessous, la carte d’interface réseau (NIC) est nommée eth0, ce qui correspond à la base 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 valeurs maximales prédéfinies avec la commande suivante. Remplacez eth0 parle nom de votre carte réseau (NIC) :
```
ethtool -g eth0
```
Définissez la taille de mémoire tampon de rx (réception) et de tx (transmission) sur 4 Ko :
```
ethtool -G eth0 rx 4096 tx 4096
```
Vérifiez que la valeur est correctement configurée :
```
ethtool -g eth0
```
Activez 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 bien en charge les trames Jumbo. Ce n’est que dans ce cas que l’activation des trames Jumbo 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 de sp_configure, comme indiqué ci-dessous :
```
# 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
```
```
EXEC sp_configure 'network packet size', '8060';
GO
RECONFIGURE WITH OVERRIDE;
GO
```
Par défaut, nous vous recommandons de définir le port pour la fusion des IRQ RX/TX adaptatives, ce qui signifie que la remise des interruptions est ajustée pour améliorer la latence quand le taux de paquets est faible et améliorer le débit quand le taux de paquets est élevé. Ce paramètre peut ne pas être disponible dans l’ensemble de l’infrastructure réseau. Vérifiez donc l’infrastructure réseau existante et confirmez qu’elle est prise en charge. L’exemple ci-dessous correspond à une carte d’interface réseau nommée eth0, de base Intel :
1. Définissez le port pour la fusion adaptative RX/TX IRQ :
```
ethtool -C eth0 adaptive-rx on
ethtool -C eth0 adaptive-tx on
```
2. Confirmez le paramètre :
```
ethtool -c eth0
```
Notes

Pour obtenir un comportement prévisible dans les environnements hautes performances, comme ceux utilisés comme points de référence, désactivez la fusion des IRQ RX/TX adaptatives, puis définissez spécifiquement la fusion des interruptions 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 fusion adaptative RX/TX IRQ :
```
ethtool -C eth0 adaptive-rx off
ethtool -C eth0 adaptive-tx off
```
Confirmez la modification.
```
ethtool -c eth0
```
Définissez les paramètres rx-usecs et irq . rx-usecs spécifie le nombre de microsecondes avant de générer une interruption après qu’au moins 1 paquet ait été reçu. Le paramètre irq les délais de mise à jour de l'état lorsque l'interruption est désactivée. Pour les cartes réseau de base Intel, vous pouvez utiliser les paramètres suivants :
```
ethtool -C eth0 rx-usecs 100 tx-frames-irq 512
```
Confirmez la modification.
```
ethtool -c eth0
```
Nous vous recommandons également d’activer RSS et, par défaut, de combiner les côtés RX et TX des files d’attente RSS. Dans certains scénarios spécifiques impliquant le Support Microsoft, la désactivation de RSS a également permis d’améliorer 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
```
Utilisation de l’affinité d’IRQ des ports de la carte réseau. Pour obtenir les performances attendues en modifiant l’affinité d’IRQ, vous devez tenir compte de quelques paramètres importants tels que la gestion par Linux de la topologie du serveur, la pile de pilotes de la carte réseau, les paramètres par défaut et le paramètre irqbalance. Pour optimiser les paramètres d’affinité d’IRQ des ports de la carte réseau, vous devez connaître la topologie du serveur, désactiver irqbalance et utiliser 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 d’optimisation des performances pour les cartes réseau Mellanox. Les commandes varient en fonction de l’environnement. Pour plus d’informations, contactez le fournisseur de votre carte réseau.

Désactivez irqbalance, ou obtenez un instantané des paramètres IRQ et forcez le démon à quitter :
```
systemctl disable irqbalance.service
```
Ou :
```
irqbalance --oneshot
```
Vérifiez que est common_irq_affinity.sh exécutable :
```
chmod +x common_irq_affinity.sh
```
Affichez l’affinité IRQ pour le port de carte réseau Mellanox (par exemple, eth0) :
```
./show_irq_affinity.sh eth0
```
Optimisez les performances de débit optimales avec un outil Mellanox :
```
./mlnx_tune -p HIGH_THROUGHPUT
```
Définissez l’affinité matérielle avec le nœud NUMA qui héberge physiquement la carte réseau et son port :
```
./set_irq_affinity_bynode.sh `\cat /sys/class/net/eth0/device/numa_node` eth0
```
Vérifiez l’affinité IRQ :
```
./show_irq_affinity.sh eth0
```
Ajoutez des optimisations de la fusion 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
```
Une fois les modifications ci-dessus effectuées, vérifiez que la vitesse de la carte réseau correspond aux attentes à l’aide de la commande suivante :
```
ethtool eth0 | grep -i Speed
```

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

Pour des performances optimales d’E/S de stockage, utilisez la planification Linux à plusieurs files d’attente pour les appareils de traitement par blocs. Cela permet de mettre à l’échelle correctement les performances de la couche de traitement par blocs avec des disques SSD (Solid-State Drive) et des systèmes multicœurs rapides. Consultez la documentation si elle est activée par défaut dans votre distribution Linux. Dans la plupart des autres cas, le démarrage du noyau avec scsi_mod.use_blk_mq=y l’active, même si la documentation de la distribution Linux utilisée peut fournir des instructions supplémentaires à ce sujet. Celle-ci est cohérente avec le noyau Linux en amont.
Les E/S à chemins multiples étant souvent utilisées pour les déploiements SQL Server, configurez la cible multi-file d’attente du mappeur d’appareil (DM) pour utiliser l’infrastructure blk-mq en activant l’option d’amorçage du noyau dm_mod.use_blk_mq=y. La valeur par défaut est n (désactivé). Ce paramètre, lorsque les appareils SCSI sous-jacents utilisent blk-mq, réduit la surcharge de verrouillage au niveau de la couche DM. Pour plus d’informations sur la configuration des E/S à chemins multiples, 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 nœuds NUMANODE et/ou les processeurs que vous utilisez pour SQL Server (généralement pour tous les nœuds et tous les 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 garantir qu’il y a suffisamment de mémoire physique disponible pour le système d’exploitation Linux, le processus SQL Server utilise uniquement 80 % de la mémoire RAM physique par défaut. Pour certains systèmes qui ont une grande quantité de mémoire RAM physique, 20 % peut ê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. Consultez la documentation sur l'outil mssql-conf et le paramètre memory.memorylimitmb qui contrôle la mémoire visible pour SQL Server (en mégaoctets).

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.

Partage via

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

Configuration de stockage recommandée

Utiliser le sous-système de stockage avec les E/S par seconde, le débit et la redondance appropriés

Recommandations relatives à la configuration et au partitionnement de disque

suggestion de configuration du système de fichiers

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

Limitation du nombre de fichiers ouverts

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

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

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

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

Utiliser TuneD pour configurer les paramètres de noyau

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

Recommandation relative aux paramètres de processeur

Recommandations relatives aux paramètres de disque

Description

Paramètre de noyau d’équilibrage NUMA automatique pour les systèmes NUMA à plusieurs nœuds

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

Laissez les pages volumineuses transparentes (THP) activées

Recommandations relatives aux paramètres réseau

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

Configurer un fichier d’échange

Machines virtuelles et mémoire dynamique

Configuration de SQL Server

Meilleures pratiques

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

Configurer plusieurs fichiers de données `tempdb`

Configuration avancée

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

Commentaires

Ressources supplémentaires

Partage via

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

Configuration de stockage recommandée

Utiliser le sous-système de stockage avec les E/S par seconde, le débit et la redondance appropriés

Recommandations relatives à la configuration et au partitionnement de disque

suggestion de configuration du système de fichiers

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

Limitation du nombre de fichiers ouverts

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

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

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

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

Utiliser TuneD pour configurer les paramètres de noyau

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

Recommandation relative aux paramètres de processeur

Recommandations relatives aux paramètres de disque

Description

Paramètre de noyau d’équilibrage NUMA automatique pour les systèmes NUMA à plusieurs nœuds

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

Laissez les pages volumineuses transparentes (THP) activées

Recommandations relatives aux paramètres réseau

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

Configurer un fichier d’échange

Machines virtuelles et mémoire dynamique

Configuration de SQL Server

Meilleures pratiques

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

Configurer plusieurs fichiers de données tempdb

Configuration avancée

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

Contenu connexe

Commentaires

Ressources supplémentaires

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

Configurer plusieurs fichiers de données `tempdb`