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

  • Articolo

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

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.

Usare il sottosistema di archiviazione con i valori appropriati per operazioni di I/O al secondo, velocità effettiva e ridondanza

Negli ambienti locali, il fornitore dello spazio di archiviazione supporta in genere la configurazione hardware RAID appropriata con striping su più dischi per garantire i valori appropriati di operazioni di I/O al secondo, velocità effettiva e ridondanza. Questa configurazione può tuttavia variare a seconda del fornitore e dell'offerta di spazio di archiviazione in base alle diverse architetture.

Per SQL Server in Linux distribuito in Macchine virtuali di Azure, valutare l'opportunità di usare RAID software per assicurarsi che vengano soddisfatti i requisiti di operazioni di I/O al secondo e velocità effettiva appropriati. Quando si configura SQL Server in macchine virtuali di Azure con considerazioni di archiviazione analoghe, vedere Configurazione dell'archiviazione per le VM di SQL Server.

Il seguente esempio illustra come creare RAID software in Linux in Macchine virtuali 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, otto dischi dati sono stati collegati alla macchina virtuale di Azure: 4 ai file di dati dell'host, 2 per i log delle transazioni e 2 per il carico di lavoro tempdb.

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 (sunit) del file system implementata e la larghezza dello striping devono corrispondere alla geometria RAID. Ad esempio, si tratta di un esempio basato 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

La matrice di log è un RAID-10 a 6 unità con striping di 64 KB. Come si può notare:

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

Consiglio sulla configurazione del file system

SQL Server supporta i file system ext4 e XFS per l’hosting del database, dei log delle transazioni e dei file aggiuntivi, ad esempio i file di checkpoint per OLTP in memoria in SQL Server. Microsoft consiglia di 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 in modo che non venga fatta distinzione tra maiuscole e minuscole durante la creazione e la formattazione del volume XFS. Non è la configurazione più usata nell'ecosistema Linux, ma può essere usata per motivi di compatibilità.

Ad esempio, è possibile usare il comando seguente: -n version=ci viene usato 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 PMEM

Per la configurazione del file system nei dispositivi PMEM, l'allocazione dei blocchi per il file system sottostante deve essere pari a 2 MB. Per altre informazioni su questo argomento, vedere l'articolo 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 di 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 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, è necessario aggiungerle al file /etc/fstab. È anche consigliabile usare l'UUID (Universally Unique Identifier, identificatore univoco universale) in /etc/fstab per fare riferimento all'unità invece di usare solo il nome periferica, 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. Di seguito è riportato un esempio di come abilitare l'opzione noatime per un volume montato nella 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 altre informazioni sul supporto FUA da parte della distribuzione di Linux e sul relativo effetto su SQL Server, vedere SQL Server On Linux: Forced Unit Access: Forced Unit Access (FUA) Internals (SQL Server in 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

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

Configurazione consigliata:

  1. Abilitare 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 (impostazione predefinita per SQL Server nell'ecosistema Linux), assicurandosi al contempo 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 usare l'archiviazione persistente e non overlayfs.

  2. L'archiviazione deve usare il file system XFS e deve supportare FUA. 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 eseguire una query per il tipo di file system usando il comando seguente, dove <pvc-name> è PersistentVolumeClaim:

    kubectl describe pv <pvc-name>

    Nell'output, cercare fstype 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. Abilitare 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 di TuneD configurerà automaticamente alcune impostazioni del kernel e della CPU (tranne 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, il pacchetto tuned può essere installato manualmente. Può essere usato per creare e configurare il profilo mssql descritto nella sezione seguente.

Impostazioni di Linux proposte utilizzando un profilo mssql TunedD

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 successive alla 4.18, commentare le opzioni seguenti secondo le indicazioni; 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
CPU frequency governor computazionali Vedere il comando cpupower
ENERGY_PERF_BIAS computazionali Vedere il comando x86_energy_perf_policy
min_perf_pct 100 Vedere la documentazione su Intel p-state
C-States C1 only Vedere la documentazione di Linux o del sistema su come verificare che C-States sia impostato su C1 only

L'uso di TuneD come descritto in precedenza consente di configurare automaticamente e in modo appropriato le impostazioni del gestore della frequenza della CPU, di ENERGY_PERF_BIAS e di min_perf_pct grazie al profilo delle prestazioni della velocità effettiva usato come base per il profilo mssql. Il parametro C-States deve essere configurato manualmente in base alla documentazione fornita da Linux o dal distributore del 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 dato 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 di pagine di memoria del processo di runtime rispetto alla rimozione delle pagine della cache del file system in rapporto di 60:140. L'impostazione del valore 1 indica una forte preferenza per mantenere la memoria del processo di runtime in memoria fisica a spese della cache del file system. Poiché SQL Server usa il pool di buffer come cache di pagine dati e preferisce fortemente scrivere tramite l'hardware fisico ignorando la cache del file system per il ripristino affidabile, la configurazione dello scambio aggressivo può essere utile per ottenere prestazioni elevate e per SQL Server 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 del parametro rappresentano la raccomandazione corrente per la modifica dell'algoritmo CFS (Completely Fair Scheduling) nel kernel di Linux, per migliorare la velocità effettiva delle chiamate di I/O di rete e di archiviazione rispetto alla precedenza e al ripristino dei thread tra processi.

L'uso del profilo mssql TuneD configura le impostazioni vm.swappiness, vm.dirty_* e kernel.sched_*. La configurazione del disco readahead tramite il comando blockdev deve essere eseguita manualmente per ogni dispositivo.

Impostazione del kernel per il bilanciamento NUMA automatico per i sistemi NUMA a più nodi

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

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 della durata 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)

Nella maggior parte delle installazioni Linux questa opzione dovrebbe essere attiva per impostazione predefinita. Per prestazioni più coerenti, è consigliabile lasciare abilitata questa opzione di configurazione. Se tuttavia è presente un'attività di paging della memoria consistente nelle distribuzioni di SQL Server con più istanze, ad esempio, o in caso di esecuzione di SQL Server con altre applicazioni con requisiti elevati di memoria nel server, è consigliabile testare le prestazioni delle applicazioni 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

Rendere inoltre attivo il profilo mssql 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

Come per l'archiviazione e la CPU, esistono raccomandazioni specifiche per la rete, come indicato sotto per informazioni di riferimento. 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 seguente, la scheda di interfaccia di rete è denominata eth0, ovvero 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 preimpostati con il comando seguente. Sostituire eth0 con il nome della scheda di interfaccia di rete.

    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, l'abilitazione dei frame jumbo può migliorare le prestazioni. Dopo aver abilitato i frame jumbo, connettersi a SQL Server e modificare le dimensioni del pacchetto di rete impostando 8060 con sp_configure come illustrato sotto:

    # 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

  3. Per impostazione predefinita, è consigliabile impostare la porta per la coalescenza RX/TX IRQ adattiva, il che significa che l'interruzione del recapito viene modificata 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 in tutte le diverse infrastrutture di rete, quindi è consigliabile esaminare l'infrastruttura di rete esistente e verificare che sia supportata. L'esempio seguente riguarda la scheda di interfaccia di rete denominata eth0, ovvero 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 avere un comportamento prevedibile per gli ambienti con prestazioni elevate, ad esempio gli ambienti per il benchmarking, disabilitare la coalescenza RX/TX IRQ adattiva e impostare specificamente la coalescenza di interruzione 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

    Impostare i parametri rx-usecs e irq. rx-usecs specifica quanti microsecondi dopo la ricezione di almeno 1 pacchetto intercorrono 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. È anche consigliabile abilitare RSS (Receive-Side Scaling) e per impostazione predefinita, che combina il lato RX e TX delle code RSS. In alcuni scenari specifici in cui si usava il Supporto tecnico Microsoft, anche la disabilitazione di RSS ha migliorato 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 "Combinato" preimpostato. In questo esempio, il valore è impostato su 8:

    ethtool -L eth0 combined 8

    Verificare l'impostazione:

    ethtool -l eth0

  5. Uso dell'affinità IRQ della porta della scheda di interfaccia di rete. Per ottenere le prestazioni previste modificando l'affinità IRQ, prendere in considerazione alcuni parametri importanti come la gestione Linux della topologia del server, lo stack del driver della scheda di interfaccia di rete, le impostazioni predefinite e l'impostazione irqbalance. Le impostazioni di affinità IRQ della porta per la scheda di interfaccia di rete vengono ottimizzate perché si conosce la topologia del server, si disabilita irqbalance e si usano 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 interfaccia 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 fornisce fisicamente l’hosting della scheda di interfaccia di rete e della 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 completato 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 ottimali di I/O di archiviazione, usare la pianificazione a più code di Linux per i dispositivi a blocchi, che consente la scalabilità del livello di blocco con unità SSD (Solid State Drive) veloci e sistemi multi-core. Controllare nella documentazione se è abilitata per impostazione predefinita nelle distribuzioni di Linux. Nella maggior parte degli altri casi, viene abilitata avviando il kernel con scsi_mod.use_blk_mq=y, ma la documentazione della distribuzione di Linux in uso potrebbe contenere indicazioni aggiuntive. Ciò è coerente con il kernel di Linux upstream.

  • Poiché Multipath I/O viene spesso usato per le distribuzioni di SQL Server, è consigliabile configurare anche la destinazione a più code del mapper dispositivi per l'uso dell'infrastruttura blk-mq abilitando l'opzione di avvio del kernel dm_mod.use_blk_mq=y. Il valore predefinito è n (disabilitato). Questa impostazione, quando i dispositivi SCSI sottostanti usano blk-mq, riduce l'overhead dei blocchi a livello di mapper dispositivi. 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 l'installazione di 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 tutte le opzioni NUMANODE e/o le CPU usate 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 in Linux non offre un'opzione per la configurazione di più tempdb file tempdb, è consigliabile 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 la memoria fisica disponibile sia sufficiente per il sistema operativo Linux, per impostazione predefinita, il processo SQL Server usa solo l'80% della RAM fisica. Per alcuni sistemi con una grande quantità di RAM fisica, il 20% potrebbe 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. Vedere la documentazione sullo strumento mssql-conf e sull'impostazione memory.memorylimitmb che controlla la memoria visibile a SQL Server (in unità di MB).

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.

Contenuto correlato