Procedure consigliate per le prestazioni: Archiviazione, kernel, CPU e rete per SQL Server in Linux

Si applica a:SQL Server su Linux

Questo articolo illustra le raccomandazioni relative al sistema operativo e alla configurazione hardware per ottimizzare le prestazioni per SQL Server in Linux, tra cui archiviazione, kernel, CPU e impostazioni di rete.

• 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 gestire normalmente carichi di lavoro medi e di picco.

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 in Linux distribuito nelle Macchine virtuali di Azure, valutare l’uso di RAID software per garantire IOPS e velocità effettiva adeguate. Per considerazioni sull'archiviazione durante la configurazione di SQL Server in macchine virtuali Azure, vedere Configurare l'archiviazione per SQL Server nelle macchine virtuali Azure.

L'esempio seguente illustra come creare RAID software in Linux in una macchina virtuale di Azure. Usare il numero appropriato di dischi dati per soddisfare i requisiti di velocità effettiva e IOPS dei volumi in base ai dati, al log delle transazioni e ai requisiti di I/O tempdb. Nell'esempio seguente vengono collegati otto dischi dati alla macchina virtuale: quattro per ospitare i file di dati, due per i log delle transazioni e due per tempdb il carico di lavoro.

Per individuare i dispositivi (ad esempio, /dev/sdc) per la creazione RAID, utilizzare 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 puoi vedere:

• 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 SQL Server file di dati e di log delle transazioni.

Formattare il volume usando 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 quando si crea e si formatta il volume XFS. Questa configurazione non viene spesso usata nell'ecosistema Linux, ma è possibile usarla per motivi di compatibilità.

Ad esempio, eseguire 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 di 1024 file aperto predefinito (1.024). È possibile impostare limiti flessibili e rigidi su 1048576 (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

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 il sistema rimonti automaticamente le unità 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 blkid comando .

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

Alcune distribuzioni linux supportate implementano l'accesso forzato alle unità a livello di sottosistema I/O per garantire la durabilità dei dati. SQL Server sfrutta questa funzionalità per offrire prestazioni di I/O efficienti e affidabili per i carichi di lavoro Linux. Per ulteriori informazioni sul supporto FUA tra le distribuzioni Linux e il relativo effetto su SQL Server, vedere SQL Server in Linux: Forced Unit Access (FUA) Internals.

Il supporto per FUA nel sottosistema di I/O è stato introdotto in SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 e Ubuntu 18.04. In SQL Server 2017 (14.x) CU 6 e versioni successive usare la configurazione seguente per abilitare operazioni di I/O elevate ed efficienti con FUA in SQL Server.

Usare questa configurazione consigliata se vengono 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)

  Note

  A partire da SQL Server 2025 (17.x), SUSE Linux Enterprise Server (SLES) non è supportato.

• 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.

  Note

  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 hardware che supporta e è configurato per la funzionalità 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, usare la configurazione consigliata 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 una memoria di archiviazione montata 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, 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 ospita i pod di SQL Server deve usare una distribuzione e una versione Linux che supporta la funzionalità 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, 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, è possibile usare un profilo TuneD denominato mssql che offre ottimizzazioni più dettagliate relative alle prestazioni di Linux per i carichi di lavoro SQL Server. Questo profilo si basa sul profilo RHEL per le prestazioni di throughput. Poiché il mssql profilo espone tutte le relative impostazioni, è possibile esaminarle e adattarle per altre distribuzioni Linux o versioni RHEL che non includono 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, decommentare le opzioni seguenti se si utilizzano 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 usando il comando seguente:

tuned-adm active

O:

tuned-adm list

Raccomandazione sulle impostazioni della CPU

La tabella seguente fornisce suggerimenti per le impostazioni della CPU:

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:

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.

  Puoi trovare ulteriori informazioni in 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 del kernel per il bilanciamento automatico NUMA nei 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 (65.536), che potrebbe non essere sufficientemente elevata per un'installazione SQL Server. Per questo motivo, modificare il vm.max_map_count valore in almeno 262144 (262.144) per una distribuzione SQL Server. Per un'ulteriore ottimizzazione di questi parametri del kernel, vedere la sezione Impostazioni linux proposte usando un profilo mssql TuneD . Il valore massimo per vm.max_map_count è 2147483647 (2.147.483.647).

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, prendere in considerazione le raccomandazioni specifiche della rete seguenti. Diverse schede di interfaccia di rete offrono impostazioni diverse. Per indicazioni su ciascuna di queste opzioni, consultare i fornitori di NIC. Testare e configurare queste impostazioni in 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 jumbo frame, connettersi a SQL Server e modificare la dimensione del pacchetto di rete impostandola 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. Configurare il coalescing IRQ adattivo. 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:

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

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

   Confermare l'impostazione:

   ethtool -c eth0
   

   Note

   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 basate su Intel, è possibile usare le impostazioni seguenti:

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

   Confermare la modifica:

   ethtool -c eth0
   

4. Abilitare la scalabilità lato ricezione (RSS) e, per impostazione predefinita, combinare i lati 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. Configurare 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. È possibile ottimizzare le impostazioni di affinità IRQ della porta NIC usando le conoscenze 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
   

   O:

   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 raggruppamento 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. Verificare la velocità della scheda di interfaccia di rete. 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 di Device Mapper (DM) in modo che utilizzi 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 l'I/O multipath, vedere la documentazione della distribuzione 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. Se si prevede di eseguire container, abiliti lo spazio di swap sull'host.

Macchine virtuali e memoria dinamica

Se si esegue SQL Server in Linux in una macchina virtuale, assicurarsi di selezionare le opzioni che consentono di 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

Le procedure seguenti si applicano a tutte le distribuzioni di SQL Server in Linux.

Usare PROCESS AFFINITY per i nodi e le CPU

Utilizzare ALTER SERVER CONFIGURATION per impostare PROCESS AFFINITY per tutti i NUMANODE e le CPU usati per SQL Server, in genere per tutti i NODE e le CPU, su un sistema operativo Linux. L'affinità del processore consente di mantenere un comportamento efficiente di pianificazione di Linux e SQL. L'uso dell'opzione NUMANODE è il metodo più semplice. Usare PROCESS AFFINITY anche se nel computer è disponibile 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 in Linux non offre un'opzione per configurare più tempdb file, è consigliabile creare più tempdb file di dati dopo l'installazione. Per altre informazioni, vedere Raccomandazioni per ridurre la contesa di allocazione nel database tempdb di SQL Server.

Configurazione avanzata

Per le opzioni di configurazione della memoria, inclusi mssql-conf i limiti di memoria, le impostazioni cgroup, gli esempi di memoria del contenitore Docker e considerazioni sullo scambio dello spazio, vedere Procedure consigliate per le prestazioni: SQL Server memoria in Linux.

Contenuti correlati

• Procedure consigliate per le prestazioni: memoria di SQL Server su Linux
• Viste e funzioni di gestione dinamica correlate a Linux (Transact-SQL)
• Procedura dettagliata per le funzionalità delle prestazioni di SQL Server in Linux
• Che cos'è SQL Server in Linux?