Procedure consigliate per le prestazioni e linee guida per la configurazione per SQL Server in Linux

Si applica a:SQL Server - Linux

Questo articolo fornisce procedure consigliate e suggerimenti per ottimizzare le prestazioni per le applicazioni di database che si connettono a SQL Server in Linux. Questi suggerimenti sono specifici per l'esecuzione nella piattaforma Linux. Tutte i normali suggerimenti per SQL Server, ad esempio la progettazione degli indici, sono comunque validi.

Le linee guida seguenti contengono suggerimenti per la configurazione sia di SQL Server che del sistema operativo Linux. Provare a usare le impostazioni di configurazione seguenti per ottenere prestazioni ottimali per un'installazione di SQL Server.

• Raccomandazione sulla configurazione dello spazio di archiviazione
• Impostazioni del kernel e della CPU per prestazioni elevate
• Configurazione di SQL Server

Raccomandazione sulla configurazione dello spazio di archiviazione

Il sottosistema di archiviazione che ospita dati, log delle transazioni e altri file associati (ad esempio, i file di checkpoint per OLTP in memoria) deve riuscire a gestire il carico di lavoro medio e di picco in modo normale.

Utilizzare il sottosistema di archiviazione con IOPS, velocità effettiva e ridondanza adeguati

Negli ambienti locali, il fornitore di archiviazione supporta normalmente la configurazione RAID hardware appropriata con striping su più dischi per garantire IOPS, velocità effettiva e ridondanza appropriate. Tuttavia, questo supporto può differire tra diversi fornitori di archiviazione e offerte di archiviazione diverse con architetture diverse.

Per SQL Server su Linux distribuito in macchine virtuali di Azure, prendere in considerazione l'uso di RAID software per garantire i requisiti di IOPS e velocità effettiva appropriati. Quando si configura SQL Server in macchine virtuali di Azure con considerazioni di archiviazione simili, vedere Configurare l'archiviazione per SQL Server in macchine virtuali di Azure.

L'esempio seguente illustra come creare RAID software in Linux in una macchina virtuale di Azure. Tenere conto che è consigliabile usare il numero corretto di dischi dati per la produttività e le operazioni di I/O al secondo necessarie per i volumi in base ai requisiti relativi ai dati, al log delle transazioni e alle operazioni di I/O di tempdb. Nell'esempio seguente sono stati collegati otto dischi dati alla macchina virtuale; quattro per ospitare i file di dati, due per i log delle transazioni e due per il tempdb carico di lavoro.

Per individuare i dispositivi (ad esempio /dev/sdc) per la creazione raid, usare il comando 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

Consigli sul partizionamento e la configurazione dei dischi

Per SQL Server, usare una configurazione RAID. L'unità di striping del file system distribuita (sunit) e la larghezza di striping corrispondono alla geometria RAID. L'esempio seguente mostra ad esempio una configurazione basata su XFS per un volume di log.

# 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

L'array di log è un RAID-10 a sei unità con uno striping di 64 KB. Come si può notare:

• Per sunit=16 blks, blocco di dimensione 16 * 4096 = 64 KB, corrisponde alla dimensione della stripe.
• Per swidth=48 blks, swidth / sunit = 3, ovvero il numero di unità dati nella matrice, escluse le unità di parità.

Configurazione consigliata del file system

SQL Server supporta i file system ext4 e XFS utilizzati per ospitare il database, i log delle transazioni e altri file, come ad esempio i file di checkpoint per OLTP in memoria in SQL Server. Usare il file system XFS per ospitare i file di dati e di log delle transazioni di SQL Server.

Formattare il volume con il file system XFS:

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

È possibile configurare il file system XFS senza distinzione tra maiuscole e minuscole durante la creazione e la formattazione del volume XFS. Questa configurazione non viene spesso usata nell'ecosistema Linux, ma può essere usata per motivi di compatibilità.

Ad esempio, è possibile usare il comando seguente: Usare -n version=ci per configurare il file system XFS senza distinzione tra maiuscole e minuscole.

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

Consiglio sul filesystem per memoria persistente

Per la configurazione del file system nei dispositivi Memoria persistente, impostare l'allocazione dei blocchi per il file system sottostante su 2 MB. Per altre informazioni, vedere Considerazioni tecniche.

Limitazione di apertura dei file

L'ambiente di produzione potrebbe richiedere più connessioni rispetto al limite predefinito di 1.024 file aperti. È possibile impostare limiti flessibili e rigidi su 1.048.576. Ad esempio, in RHEL, modificare il file /etc/security/limits.d/99-mssql-server.conf in modo che abbia i valori seguenti:

mssql - nofile 1048576

Nota

Questa impostazione non si applica ai servizi di SQL Server avviati da systemd. Per altre informazioni, vedere Come impostare i limiti per i servizi in RHEL e systemd.

Disabilitare la data e l'ora dell'ultimo accesso nei file system per i file di dati e di log di SQL Server

Per assicurarsi che le unità collegate al sistema vengano rimontate automaticamente dopo un riavvio, aggiungerle al /etc/fstab file. Usare l'UUID (Universally Unique Identifier) in /etc/fstab per fare riferimento all'unità, anziché solo al nome del dispositivo ( ad esempio /dev/sdc1).

Usare l'attributo noatime con qualsiasi file system usato per archiviare i file di dati e i file log di SQL Server. Per informazioni su come impostare questo attributo, vedere la documentazione di Linux. L'esempio seguente illustra come abilitare l'opzione noatime per un volume montato in una macchina virtuale di Azure.

Immissione del punto di montaggio in /etc/fstab:

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

Nell'esempio precedente, UUID rappresenta il dispositivo che è possibile trovare usando il comando blkid.

SQL Server e funzionalità del sottosistema di I/O FUA (Forced Unit Access)

Alcune versioni di distribuzioni Linux supportate forniscono supporto per la funzionalità del sottosistema di I/O FUA per garantire la durabilità dei dati. SQL Server usa la capacità FUA per garantire operazioni di I/O estremamente efficienti e affidabili per il carico di lavoro di SQL Server. Per ulteriori informazioni sul supporto FUA dalle distribuzioni Linux e il suo effetto su SQL Server, vedere SQL Server On Linux: Forced Unit Access (FUA) Internals (SQL Server su Linux: elementi interni di FUA - Forced Unit Access).

SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 e Ubuntu v. 18.04 hanno introdotto il supporto per la capacità FUA nel sottosistema di I/O. Se si usa SQL Server 2017 (14.x) CU 6 e versioni successive, è consigliabile usare la configurazione seguente per un'implementazione I/O a prestazioni elevate ed efficiente con FUA tramite SQL Server.

Usare questa configurazione consigliata se sono soddisfatte le condizioni seguenti.

• SQL Server 2017 (14.x) CU 6 e versioni successive

• Uso di una distribuzione e una versione di Linux che supportano la capacità FUA (a partire da Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 o Ubuntu 18.04)

• File system XFS per l'archiviazione di SQL Server, nel kernel Linux 4.18 o versioni successive.

• ext4 file system per l'archiviazione di SQL Server, nel kernel Linux 5.6 o versioni successive.

  Nota

  È consigliabile usare il file system XFS per l'hosting di file di dati e log delle transazioni di SQL Server quando la versione del kernel Linux è inferiore alla 5.6. A partire dalla versione 5.6 del kernel, è possibile scegliere tra XFS e ext4 in base ai requisiti specifici.

• Sottosistema di archiviazione e/o hardware che supporta ed è configurato per la capacità FUA

Configurazione consigliata:

1. Abilita il flag di traccia 3979 come parametro di avvio.

2. Usare mssql-conf per configurare control.writethrough = 1 e control.alternatewritethrough = 0.

Per quasi tutte le altre configurazioni che non soddisfano le condizioni precedenti, la configurazione consigliata è la seguente:

1. Abilitare il flag di traccia 3982 come parametro di avvio (ovvero l'impostazione predefinita per SQL Server nell'ecosistema Linux) e assicurarsi che il flag di traccia 3979 non sia abilitato come parametro di avvio.

2. Usare mssql-conf per configurare control.writethrough = 1 e control.alternatewritethrough = 1.

Supporto FUA per i contenitori di SQL Server implementati in Kubernetes

1. SQL Server deve utilizzare l'archiviazione montata e persistente, e non overlayfs.

2. L'archiviazione deve usare i file system XFS o ext4 e deve supportare FUA (ext4 non supporta FUA nel kernel Linux precedente alla versione 5.6). Prima di abilitare questa impostazione, è bene collaborare con il fornitore di distribuzione e archiviazione Linux per assicurarsi che il sistema operativo e il sottosistema di archiviazione supportino le opzioni FUA. In Kubernetes, è possibile interrogare il tipo di filesystem usando il comando seguente, dove <pvc-name> è PersistentVolumeClaim:

   kubectl describe pv <pvc-name>
   

   Nell'output, cercare il fstype che è impostato su XFS.

3. Il nodo di lavoro che con hosting dei pod di SQL Server deve utilizzare una distribuzione e una versione di Linux che supportano la capacità FUA (a partire da Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 o Ubuntu 18.04)

Se vengono soddisfatte le condizioni precedenti, è possibile usare le impostazioni FUA consigliate seguenti.

1. Abilita il flag di traccia 3979 come parametro di avvio.

2. Usare mssql-conf per configurare control.writethrough = 1 e control.alternatewritethrough = 0.

Impostazioni del kernel e della CPU per prestazioni elevate

La sezione seguente descrive le impostazioni consigliate per il sistema operativo Linux per ottenere prestazioni e velocità effettiva elevate per un'installazione di SQL Server. Per il processo di configurazione di queste impostazioni, vedere la documentazione della distribuzione di Linux. È possibile usare TuneD come illustrato per configurare molte CPU e configurazioni del kernel, descritte nella sezione successiva.

Usare TuneD per configurare le impostazioni del kernel

Per gli utenti di Red Hat Enterprise Linux (RHEL), il profilo delle prestazioni della velocità effettiva TuneD configura automaticamente alcune impostazioni del kernel e della CPU (ad eccezione di C-States). A partire da RHEL 8.0, è stato sviluppato in collaborazione con Red Hat un profilo di TuneD denominato mssql, che offre ottimizzazioni più dettagliate correlate alle prestazioni di Linux per i carichi di lavoro di SQL Server. Questo profilo include il profilo di prestazioni per la velocità effettiva RHEL e le definizioni sono presentate di seguito per poterle confrontare con altre distribuzioni di Linux e versioni di RHEL senza questo profilo.

Per SUSE Linux Enterprise Server 12 SP5, Ubuntu 18.04 e Red Hat Enterprise Linux 7.x, è possibile installare manualmente il tuned pacchetto. Usarlo per creare e configurare il mssql profilo come descritto nella sezione seguente.

Impostazioni di Linux proposte utilizzando un profilo mssql TuneD

Nell'esempio seguente, viene fornita una configurazione TuneD per SQL Server in 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

Se si usano distribuzioni Linux con versioni del kernel superiori alla 4.18, impostare come illustrato le opzioni seguenti. in caso contrario, rimuovere il commento dalle opzioni seguenti se si usano distribuzioni con versioni del kernel precedenti alla 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

Per abilitare questo profilo TuneD, salvare le definizioni in un file tuned.conf in una cartella /usr/lib/tuned/mssql e abilitare il profilo usando i comandi seguenti:

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

Verificare che il profilo sia attivo, con il comando seguente:

tuned-adm active

Oppure:

tuned-adm list

Raccomandazione sulle impostazioni della CPU

La tabella seguente fornisce suggerimenti per le impostazioni della CPU:

Impostazione	Valore	Ulteriori informazioni
gestore della frequenza della CPU	prestazioni	Vedere il comando cpupower
BIAS_PRESTAZIONI_ENERGETICHE	prestazioni	Vedere il comando x86_energy_perf_policy
percentuale_minima_di_prestazione	100	Consulta la documentazione su Intel p-state
Stati C	Solo C1	Vedere la documentazione di Linux o del sistema su come verificare che C-States sia impostato su C1 only

Quando si usa TuneD come descritto, configura automaticamente le impostazioni di Controllo frequenza CPU, ENERGY_PERF_BIASe min_perf_pct . Utilizza il profilo di throughput-prestazioni come base per il profilo mssql. È necessario configurare manualmente il parametro C-States in base alla documentazione fornita da Linux o dal server di distribuzione di sistema.

Raccomandazioni sulle impostazioni del disco

La tabella seguente fornisce suggerimenti per le impostazioni del disco:

Impostazione	Valore	Ulteriori informazioni
readahead del disco	4096	Vedere il comando blockdev
impostazioni 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	Vedere il comando sysctl

Descrizione

• vm.swappiness: questo parametro controlla il peso relativo assegnato allo scambio della memoria del processo di runtime rispetto alla cache del file system. Il valore predefinito per questo parametro è 60, che indica lo scambio delle pagine di memoria del processo di runtime rispetto alla rimozione delle pagine della cache del file system con un rapporto di 60:140. L'impostazione del valore su 1 indica una forte preferenza per mantenere la memoria del processo di runtime nella memoria fisica a scapito della cache del file system. Poiché SQL Server usa il pool di buffer come cache delle pagine di dati e preferisce scrivere direttamente sull'hardware fisico ignorando la cache del file system per un ripristino affidabile, una configurazione di swappiness aggressiva può essere utile per SQL Server ad alte prestazioni e dedicato.

  È possibile trovare altre informazioni nella documentazione di /proc/sys/vm/ - #swappiness

• vm.dirty_*: gli accessi in scrittura dei file di SQL Server non vengono memorizzati nella cache, soddisfacendo i requisiti di integrità dei dati. Questi parametri consentono di ottenere prestazioni elevate di scrittura asincrona e di ridurre l'effetto delle operazioni di scrittura nella cache di Linux sulle operazioni I/O di archiviazione, consentendo una memorizzazione nella cache sufficiente limitando al contempo lo svuotamento.

• kernel.sched_*: questi valori dei parametri rappresentano la raccomandazione corrente per modificare l'algoritmo Completamente Fair Scheduling (CFS) nel kernel Linux. Migliorano la velocità effettiva delle chiamate di I/O di rete e archiviazione in relazione alla precedenza tra processi e alla ripresa dei thread.

L'uso del profilo TuneD mssql configura le impostazioni vm.swappiness, vm.dirty_* e kernel.sched_*. È necessario configurare manualmente l'impostazione del disco readahead usando il blockdev comando per ogni dispositivo.

Impostazione automatica del bilanciamento NUMA del kernel per sistemi NUMA multinodo

Se si installa SQL Server in un sistema NUMA multinodo, l'impostazione del kernel seguente kernel.numa_balancing è abilitata per impostazione predefinita. Per consentire a SQL Server di operare al massimo efficienza in un sistema NUMA, disabilitare il bilanciamento automatico NUMA in un sistema NUMA multinodo:

sysctl -w kernel.numa_balancing=0

L'uso del profilo mssql TuneD configura l'opzione kernel.numa_balancing.

Impostazioni del kernel per lo spazio indirizzi virtuali

L'impostazione predefinita di vm.max_map_count (65536) potrebbe non essere sufficientemente elevata per un'installazione di SQL Server. Per questo motivo, cambiare il valore vm.max_map_count in almeno 262144 per una distribuzione di SQL Server e vedere la sezione Impostazioni di Linux proposte con un profilo mssql TuneD per altre ottimizzazioni di questi parametri del kernel. Il valore massimo per vm.max_map_count è 2147483647.

sysctl -w vm.max_map_count=1600000

L'uso del profilo mssql TuneD configura l'opzione vm.max_map_count.

Lasciare abilitate le pagine THP (Transparent Huge Page)

Per impostazione predefinita, la maggior parte delle installazioni linux è attiva. Per un'esperienza di prestazioni più coerente, lasciare abilitata questa opzione di configurazione. Tuttavia, se è presente un'attività di paging di memoria elevata nelle distribuzioni di SQL Server con più istanze o l'esecuzione di SQL Server con altre applicazioni che richiedono memoria nel server, testare le prestazioni dell'applicazione dopo l'esecuzione del comando seguente:

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

In alternativa, modificare il profilo mssql TuneD con la riga:

vm.transparent_hugepages=madvise

Assicurarsi che il mssql profilo sia attivo dopo la modifica:

tuned-adm off
tuned-adm profile mssql

L'uso del profilo mssql TuneD configura l'opzione transparent_hugepage.

Raccomandazioni sull'impostazione di rete

Oltre alle raccomandazioni relative all'archiviazione e alla CPU, sono disponibili raccomandazioni specifiche per la rete. Per riferimento, sono elencate le raccomandazioni seguenti. Non tutte le impostazioni negli esempi seguenti sono disponibili in schede di interfaccia di rete diverse. Fare riferimento e consultare i fornitori delle schede di interfaccia di rete per indicazioni su ognuna di queste opzioni. Testare e configurare queste opzioni negli ambienti di sviluppo prima di applicarle agli ambienti di produzione. Le opzioni seguenti sono illustrate con gli esempi e i comandi usati sono specifici per il tipo di interfaccia di rete e di fornitore.

1. Configurazione della dimensione buffer delle porte di rete. Nell'esempio la scheda di interfaccia di rete è denominata eth0, che è una scheda di interfaccia di rete basata su Intel. Per la scheda di interfaccia di rete basata su Intel, la dimensione buffer consigliata è 4 KB (4096). Verificare i valori massimi preimpostati e quindi configurarli usando l'esempio seguente:

   Controllare i valori massimi predefiniti con il comando seguente. Sostituire eth0 con il nome del NIC.

   ethtool -g eth0
   

   Impostare la dimensione buffer rx (ricezione) e tx (trasmissione) su 4 KB:

   ethtool -G eth0 rx 4096 tx 4096
   

   Verificare che il valore sia configurato correttamente:

   ethtool -g eth0
   

2. Abilitare i frame jumbo. Prima di abilitare i frame jumbo, verificare che tutti i commutatori di rete, i router e qualsiasi altro elemento essenziale nel percorso del pacchetto di rete tra i client e SQL Server supportino i frame jumbo. Solo in questo caso è possibile abilitare i jumbo frame per migliorare le prestazioni. Dopo aver abilitato i frame jumbo, connettersi a SQL Server e modificare le dimensioni del pacchetto di rete su 8060 usando sp_configure, come illustrato nell'esempio seguente:

   # 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. Per impostazione predefinita, impostare la porta per l'unione adattiva di RX/TX IRQ, ovvero il recapito degli interrupt viene regolato per migliorare la latenza quando la velocità dei pacchetti è bassa e migliorare la velocità effettiva quando la velocità dei pacchetti è elevata. Questa impostazione potrebbe non essere disponibile nell'infrastruttura di rete, quindi esaminare l'infrastruttura di rete esistente e verificare che questa impostazione sia supportata. L'esempio è relativo alla scheda di interfaccia di rete denominata eth0, che è una scheda di interfaccia di rete basata su Intel:

   1. Impostare la porta per la coalescenza RX/TX IRQ adattiva:

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

   2. Confermare l’impostazione:

      ethtool -c eth0
      

   Nota

   Per un comportamento prevedibile in ambienti ad alte prestazioni, come quelli per il benchmarking, disabilitare la coalescenza adattiva di RX/TX IRQ e quindi impostare in modo specifico la coalescenza delle interruzioni RX/TX. Vedere i comandi di esempio per disabilitare la coalescenza RX/TX IRQ e poi impostare in modo specifico i valori:

   Disabilitare la coalescenza RX/TX IRQ adattiva:

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

   Confermare la modifica:

   ethtool -c eth0
   

   Imposta i parametri rx-usecs e irq. rx-usecs specifica il numero di microsecondi dopo la ricezione di almeno un pacchetto prima di generare un interrupt. Il parametro irq specifica i ritardi corrispondenti nell'aggiornamento dello stato quando l'interrupt è disabilitato. Per le schede di interfaccia di rete di base Intel, è possibile usare le impostazioni seguenti:

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

   Confermare la modifica:

   ethtool -c eth0
   

4. Abilitare il ridimensionamento lato ricezione (RSS) e, per impostazione predefinita, combinare il lato RX e TX delle code RSS. Esistono scenari specifici, quando si lavora con il supporto tecnico Microsoft, in cui la disabilitazione di RSS migliora anche le prestazioni. Testare questa impostazione negli ambienti di test prima di applicarla negli ambienti di produzione. L'esempio seguente riguarda le schede di interfaccia di rete Intel.

   Ottenere i valori massimi predefiniti:

   ethtool -l eth0
   

   Combinare le code con il valore riportato nel valore massimo preimpostato denominato "Combinato". In questo esempio, il valore è impostato su 8:

   ethtool -L eth0 combined 8
   

   Verificare l'impostazione:

   ethtool -l eth0
   

5. Lavorare con l'affinità IRQ della porta NIC. Per ottenere le prestazioni previste modificando l'affinità IRQ, considerare alcuni parametri importanti, come la gestione da parte di Linux della topologia del server, lo stack di driver NIC, le impostazioni predefinite e irqbalance impostazione. Le ottimizzazioni delle impostazioni di affinità IRQ della porta NIC vengono eseguite con la conoscenza della topologia del server, disabilitando irqbalancee usando le impostazioni specifiche del fornitore della scheda di interfaccia di rete.

   Di seguito è riportato un esempio dell'infrastruttura di rete specifica di Mellanox per spiegare la configurazione. Per altre informazioni, e per scaricare gli strumenti mlnx di Mellanox, vedere Strumenti di ottimizzazione delle prestazioni per le schede di rete Mellanox. I comandi cambiano in base all'ambiente. Per altre indicazioni, contattare il fornitore della scheda di interfaccia di rete.

   Disabilitare irqbalance oppure ottenere uno snapshot delle impostazioni IRQ e forzare l'uscita del daemon:

   systemctl disable irqbalance.service
   

   Oppure:

   irqbalance --oneshot
   

   Assicurarsi che common_irq_affinity.sh sia eseguibile:

   chmod +x common_irq_affinity.sh
   

   Visualizzare l'affinità IRQ per la porta della scheda di rete Mellanox (ad esempio eth0):

   ./show_irq_affinity.sh eth0
   

   Ottimizzare per le massime prestazioni di produttività con uno strumento Mellanox:

   ./mlnx_tune -p HIGH_THROUGHPUT
   

   Impostare l'affinità hardware sul nodo NUMA che ospita fisicamente la scheda di interfaccia di rete e la relativa porta.

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

   Verificare l'affinità IRQ:

   ./show_irq_affinity.sh eth0
   

   Aggiungere ottimizzazioni di coalescenza IRQ

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

   Verificare le impostazioni:

   ethtool -c eth0
   

6. Dopo aver apportato le modifiche precedenti, verificare la velocità della scheda di interfaccia di rete per assicurarsi che corrisponda alle aspettative usando il comando seguente:

   ethtool eth0 | grep -i Speed
   

Configurazione avanzata del kernel e del sistema operativo

• Per ottenere prestazioni di I/O di archiviazione ottimali, usare lo scheduling multiqueue di Linux per i dispositivi a blocchi. Questo metodo di pianificazione consente la scalabilità ottimale delle prestazioni del livello di blocco con unità SSD (Solid State Drive) veloci e sistemi multicore. Controllare la documentazione per verificare se la distribuzione linux lo abilita per impostazione predefinita. Nella maggior parte degli altri casi, è possibile avviare il kernel con scsi_mod.use_blk_mq=y per abilitarlo. La documentazione per la distribuzione linux potrebbe avere altre indicazioni su questa impostazione. Questa impostazione è coerente con il kernel Linux upstream.

• Poiché l'I/O multipath viene spesso usato per le distribuzioni di SQL Server, configurare la destinazione multiqueue del mapper dei dispositivi (DM) per utilizzare l'infrastruttura blk-mq, abilitando l'opzione di avvio del kernel dm_mod.use_blk_mq=y. Il valore predefinito è n (disabilitato). Questa impostazione riduce il sovraccarico di blocco a livello DM quando i dispositivi SCSI sottostanti usano blk-mq. Per altre informazioni su come configurare Multipath I/O, vedere la documentazione della distribuzione di Linux.

Configurare un file di scambio

Assicurarsi di avere un file di scambio configurato correttamente per evitare problemi di memoria insufficiente. Per informazioni sulla creazione e il corretto dimensionamento di un file di scambio, vedere la documentazione di Linux.

Macchine virtuali e memoria dinamica

Se si esegue SQL Server in Linux in una macchina virtuale, assicurarsi di selezionare le opzioni per correggere la quantità di memoria riservata per la macchina virtuale. Non usare funzionalità come la memoria dinamica di Hyper-V.

Configurazione di SQL Server

Eseguire le attività di configurazione seguenti dopo aver installato SQL Server in Linux per ottenere prestazioni ottimali per l'applicazione.

Procedure consigliate

Usare PROCESS AFFINITY per il nodo e/o le CPU

Usare ALTER SERVER CONFIGURATION per impostare PROCESS AFFINITY per tutti i NUMANODE e le CPU utilizzati per SQL Server (in genere per tutti i nodi e le CPU) in un sistema operativo Linux. L'affinità processori consente di mantenere efficiente il comportamento di pianificazione di SQL e Linux. L'uso dell'opzione NUMANODE è il metodo più semplice. Usare PROCESS AFFINITY anche se nel computer è presente un solo nodo NUMA. Per altre informazioni su come impostare PROCESS AFFINITY, vedere l'articolo ALTER SERVER CONFIGURATION.

Configurare più file di dati tempdb

Poiché un'installazione di SQL Server su Linux non offre un'opzione di configurazione per più file tempdb, è consigliabile considerare di creare più file di dati tempdb dopo l'installazione. Per altre informazioni, vedere le linee guida nell'articolo Suggerimenti per ridurre la contesa per l'allocazione nel database tempdb di SQL Server.

Configurazione avanzata

I suggerimenti seguenti sono impostazioni di configurazione facoltative che è possibile scegliere di eseguire dopo l'installazione di SQL Server in Linux. Queste scelte sono basate sui requisiti del carico di lavoro e sulla configurazione del sistema operativo Linux.

Impostare un limite di memoria con mssql-conf

Per assicurarsi che sia disponibile memoria fisica sufficiente per il sistema operativo Linux, il processo di SQL Server usa solo 80% della RAM fisica per impostazione predefinita. Per alcuni sistemi con grandi quantità di RAM fisica, 20% potrebbero essere un numero significativo.

Ad esempio, in un sistema con 1 TB di RAM, l'impostazione predefinita lascerà circa 200 GB di RAM inutilizzata. In questo caso, potrebbe essere necessario configurare il limite di memoria su un valore superiore. È possibile modificare questo valore con lo strumento mssql-conf . Per altre informazioni, vedere l'impostazione memory.memorylimitmb che controlla la memoria visibile a SQL Server (in unità di MB).

Nota

È anche possibile configurare un limite di memoria usando la MSSQL_MEMORY_LIMIT_MB variabile di ambiente. Questo metodo viene comunemente usato quando si distribuiscono contenitori o si automatizzano le distribuzioni basate su pacchetti o contenitori di SQL Server. La MSSQL_MEMORY_LIMIT_MB variabile di ambiente ha la precedenza sull'impostazione memory.memorylimitmb .

Quando si modifica questa impostazione, cercare di non impostare un valore troppo elevato. Se non si lascia memoria sufficiente, è possibile che si verifichino problemi con il sistema operativo Linux e con altre applicazioni Linux.

Configurare i limiti di memoria con il gruppo di controllo (cgroup) v2

A partire da SQL Server 2025 (17.x) e SQL Server 2022 (16.x) CU 20, SQL Server rileva e rispetta i vincoli del gruppo di controllo (cgroup) v2, migliorando la stabilità delle prestazioni e l'isolamento delle risorse in ambienti Docker, Kubernetes e OpenShift. I gruppi di controllo consentono un controllo con granularità fine nel kernel Linux sulle risorse di sistema, ad esempio CPU e memoria.

Con il supporto di cgroup v2, SQL Server riduce gli errori di memoria insufficiente (OOM) osservati in precedenza nelle distribuzioni in contenitori, in particolare nei cluster Kubernetes (ad esempio, servizio Azure Kubernetes v1.25+), in cui non sono stati applicati limiti di memoria definiti nelle specifiche del contenitore.

Controllare la versione di cgroup

stat -fc %T /sys/fs/cgroup

I risultati sono i seguenti:

Result	Descrizione
cgroup2fs	Si sta usando cgroup v2
cgroup	Si sta usando cgroup v1

Passare a cgroup v2

Il percorso più semplice consiste nella scelta di una distribuzione che supporta cgroup v2 predefinita.

Se è necessario passare manualmente, aggiungere la riga seguente alla configurazione GRUB:

systemd.unified_cgroup_hierarchy=1

Eseguire quindi il comando seguente per aggiornare GRUB:

sudo update-grub

Per altre informazioni, vedere le risorse seguenti:

• Guida introduttiva: Distribuire un contenitore Linux di SQL Server in Kubernetes usando i grafici Helm
• Documentazione del kernel Linux cgroup v2
• Gruppo di controllo v2

Linee guida per l'impostazione dei limiti di memoria

Quando si impostano i limiti di memoria per SQL Server in Linux, prendere in considerazione le linee guida seguenti:

• Usare cgroup per limitare la memoria complessiva disponibile per il contenitore. Questa impostazione stabilisce il limite superiore per tutti i processi all'interno del contenitore.

• Il limite di memoria (impostato da memorylimitmb o variabile MSSQL_MEMORY_LIMIT_MB di ambiente) controlla la memoria totale che SQL Server in Linux può allocare in tutti i relativi componenti, ad esempio il pool di buffer, SQLPAL, SQL Server Agent, LibOS, PolyBase, Full-Text Search e qualsiasi altro processo caricato in SQL Server in Linux.

• La MSSQL_MEMORY_LIMIT_MB variabile di ambiente ha la precedenza su memorylimitmb definita in mssql.conf.

• memorylimitmb non può superare la memoria fisica effettiva del sistema host.

• Impostare memorylimitmb un valore inferiore alla memoria del sistema host e al limite di cgroup (se presente), per assicurarsi che sia disponibile memoria fisica sufficiente per il sistema operativo Linux. Se non si imposta memorylimitmbin modo esplicito , SQL Server usa 80% del valore minore tra la memoria totale di sistema e il limite cgroup (se presente).

• L'opzione di configurazione del server max_server_memory limita solo le dimensioni del pool di buffer di SQL Server e non regola l'utilizzo complessivo della memoria per SQL Server in Linux. Impostare sempre questo valore inferiore a memorylimitmb per garantire che rimanga memoria sufficiente per altri componenti, ad esempio SQLPAL, SQL Server Agent, LibOS, PolyBase, Full-Text Search e qualsiasi altro processo caricato in SQL Server su Linux.

Contenuto correlato

• Procedura dettagliata per le funzionalità delle prestazioni di SQL Server in Linux
• Che cos'è SQL Server in Linux?