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

Si applica a: SQL Server (tutte le versioni supportate) - 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.

Configurazione del sistema operativo Linux

Provare a usare le impostazioni di configurazione del sistema operativo Linux seguenti per ottenere prestazioni ottimali per un'installazione di SQL Server.

Raccomandazione sulla configurazione dello spazio di archiviazione

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

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. 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, vedere l'articolo seguente per considerazioni simili sull'archiviazione: Configurazione dell'archiviazione per le VM di SQL Server

Il seguente è un esempio di come creare RAID software in Linux in Macchine virtuali di Azure. Di seguito è riportato un esempio, ma è consigliabile usare il numero appropriato di dischi dati per la velocità effettiva 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. In questo esempio otto dischi dati sono stati collegati alla macchina virtuale di Azure: quattro ai file di dati dell'host, due per i log delle transazioni e due per il carico di lavoro tempdb.

# To locate the devices (for example /dev/sdc) for RAID creation, use the lsblk command
# 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 di partizionamento e configurazione del disco

Per SQL Server, è consigliabile usare configurazioni RAID. L'unità di striscia del file system distribuita (sunit) e la larghezza di striscia devono corrispondere alla geometria RAID. Ecco un esempio basato su file system 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/sda1 -f -L log 
meta-data=/dev/sda1              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 una striscia di 64k. Come si può notare:

  • Il "sunit=16 blks", 16*4096 blk size= 64k, corrisponde alla dimensione della striscia.
  • Il "swidth = 48 blks", swidth/sunit = 3, ovvero il numero di unità dati nella matrice, escluse le unità di parità.

Raccomandazione sulla configurazione del file system

SQL Server supporta i file system EXT4 e XFS per ospitare il database, i log delle transazioni e i 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.

# Formatting the volume with XFS filesystem
mkfs.xfs /dev/md0 -f -L datavolume
mkfs.xfs /dev/md1 -f -L logvolume
mkfs.xfs /dev/md2 -f -L tempdb

Nota

È 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à.

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

Nell'esempio vengono usati i parametri -n version=ci per configurare il file system XFS in modo che non venga fatta distinzione tra maiuscole e minuscole.

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

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 che l'UUID (Universally Unique IDentifier) usato in /etc/fstab faccia riferimento all'unità invece che al solo nome del dispositivo, ad esempio /dev/sdc1.

L'uso dell'attributo noatime con qualsiasi file system usato per archiviare i file di dati e di log di SQL Server è vivamente consigliato. 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.

Ingresso 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 funzionalità FUA per garantire operazioni di I/O estremamente efficienti e affidabili per il carico di lavoro di SQL Server. Per altre informazioni sul supporto di FUA nella distribuzione Linux e sull'impatto per SQL Server, vedere il blog seguente: SQL Server On Linux: Forced Unit Access (FUA) Internals (SQL Server in Linux: elementi interni di FUA - Forced Unit Access)

SUSE Linux Enterprise Server 12 SP5 e Red Hat Enterprise Linux 8.0 e versioni successive supportano la funzionalità FUA nel sottosistema di I/O. Se si usa SQL Server 2017 CU6 e versioni successive o SQL Server 2019, è consigliabile usare la configurazione seguente per un'implementazione a prestazioni elevate ed efficiente dell'input/output con FUA tramite SQL Server.

Usare la configurazione consigliata riportata di seguito se sono soddisfatte le condizioni seguenti.

  • Uso di SQL Server 2017 CU6 o versione successiva oppure di SQL Server 2019
  • Uso di una distribuzione e una versione di Linux che supportano la funzionalità FUA (Red Hat Enterprise Linux 8.0 o versione successiva oppure SUSE Linux Enterprise Server 12 SP5)
  • Sottosistema di archiviazione e/o hardware che supporta ed è configurato per la funzionalità 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

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 del sistema operativo Linux. L'uso di Tuned come descritto consente di configurare molte CPU e configurazioni del kernel descritte di seguito.

Uso di 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 co-sviluppato un profilo ottimizzato denominato mssql con Red Hat e offre ottimizzazioni correlate alle prestazioni linux per i carichi di lavoro 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 pacchetto Ottimizzato . Può essere usato per creare e configurare il profilo mssql come descritto di seguito.

Impostazioni di Linux proposte con un profilo mssql di Tuned
#
# A Tuned configuration for SQL Server on 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
#Note: If you are using Linux distributions with kernel versions greater than 4.18, please comment the following options as shown; otherwise, uncomment the following options if you are using distributions with kernel versions less than 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 di 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

Per verificare che sia abilitato, eseguire 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 prestazioni Vedere il comando cpupower
ENERGY_PERF_BIAS prestazioni 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 configura automaticamente il governatore della frequenza della CPU, ENERGY_PERF_BIAS e le impostazioni min_perf_pct in modo appropriato a causa del profilo di prestazioni della velocità effettiva usata 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 delle pagine di memoria del processo di runtime rispetto alla rimozione delle pagine della cache del file system in rapporto a 60:140. L'impostazione del valore 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 nell'hardware fisico ignorando la cache del file system per un ripristino affidabile, la configurazione dello scambio aggressivo può essere utile per le SQL Server a prestazioni elevate e dedicate. Per altre informazioni, vedere Documentazione per /proc/sys/vm/ - #swappiness

  • vm.dirty_*: SQL Server gli accessi in scrittura dei file non sono memorizzati nella cache e soddisfano i requisiti di integrità dei dati. Questi parametri consentono di ottenere prestazioni elevate di scrittura asincrona e di ridurre l'impatto delle operazioni di scrittura nella cache di Linux sulle operazioni di input/output 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, per migliorare 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 mssqlTuned configura le impostazioni vm.swappiness, vm.dirty_* e kernel.sched_* . La configurazione readahead del disco 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 multinodo, 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 mssqlTuned 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 di 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 mssqlTuned 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 mssqlTuned con la riga:

vm.transparent_hugepages=madvise

E rendere il profilo mssql attivo dopo la modifica:

tuned-adm off
tuned-adm profile mssql

L'uso del profilo mssqlTuned configura l'opzione transparent_hugepage .

Raccomandazioni per le impostazioni di rete

Analogamente alle raccomandazioni relative all'archiviazione e alla CPU, sono disponibili raccomandazioni specifiche per la rete, elencate di seguito per riferimento. Non tutte le impostazioni indicate di seguito sono disponibili in schede di interfaccia di rete diverse. Per indicazioni su ognuna di queste opzioni, vedere e consultare i fornitori di schede di interfaccia di rete. Testarlo e configurare in ambienti di sviluppo prima di applicarli agli ambienti di produzione. Le opzioni indicate di seguito sono illustrate con esempi e i comandi usati sono specifici per il tipo di scheda di interfaccia di rete e il fornitore.

  1. Configurazione delle dimensioni del buffer della porta 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 consigliata del buffer è 4 KB (4096). Verificare i valori massimi preimpostati e quindi configurarlo usando i comandi di esempio illustrati di seguito:

             #To check the pre-set maximums please run the command, example NIC name used here is:"eth0"
             ethtool -g eth0
             #command to set both the rx(recieve) and tx (transmit) buffer size to 4 KB. 
             ethtool -G eth0 rx 4096 tx 4096
             #command to check the value is properly configured is:
             ethtool -g eth0
    
  2. Abilitare i fotogrammi jumbo: prima di abilitare i fotogrammi 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 successivamente, l'abilitazione dei fotogrammi jumbo può migliorare le prestazioni. Dopo aver abilitato i fotogrammi jumbo, connettersi a SQL Server e modificare le dimensioni del pacchetto di rete su 8060 usando sp_configure come illustrato di seguito:

             #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
    
             sp_configure 'network packet size' , '8060'
             go
             reconfigure with override
             go
    
  3. Per impostazione predefinita, è consigliabile impostare la porta per il coalescing RX/TX IRQ adattivo, ovvero il recapito degli interrupt verrà modificato per migliorare la latenza quando la velocità dei pacchetti è bassa e migliorare la velocità effettiva quando la velocità dei pacchetti è elevata. Si noti che questa impostazione potrebbe non essere disponibile in tutte le diverse infrastrutture di rete, quindi esaminare l'infrastruttura di rete esistente e verificare che sia supportata. L'esempio seguente è relativo alla scheda di interfaccia di rete denominata 'eth0', che è una scheda di interfaccia di rete basata su Intel:

             #command to set the port for adaptive RX/TX IRQ coalescing
             ethtool -C eth0 adaptive-rx on
             ethtool -C eth0 adaptive-tx on
             #confirm the setting using the command:
             ethtool -c eth0
    

    Nota

    Per un comportamento prevedibile per gli ambienti ad alte prestazioni, ad esempio gli ambienti per il benchmarking, disabilitare l'unione RX/TX IRQ adattiva e quindi impostare in modo specifico l'unione di interruzioni RX/TX. Vedere i comandi di esempio per disabilitare l'unione di RX/TX IRQ e quindi impostare in modo specifico i valori:

             #commands to disable adaptive RX/TX IRQ coalescing
             ethtool -C eth0 adaptive-rx off
             ethtool -C eth0 adaptive-tx off
             #confirm the setting using the command:
             ethtool -c eth0
             #Let us set the rx-usecs parameter which specify how many microseconds after at least 1 packet is received before generating an interrupt, and the [irq] parameters are the corresponding delays in updating the #status when the interrupt is disabled. For Intel bases NICs below are good values to start with:
             ethtool -C eth0 rx-usecs 100 tx-frames-irq 512
             #confirm the setting using the command:
             ethtool -c eth0
    
  4. È anche consigliabile abilitare RSS (Receive-Side Scaling) e per impostazione predefinita, combinando il lato rx e tx delle code RSS. Ci sono stati scenari specifici in cui quando si lavora con 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. Il comando di esempio illustrato di seguito è relativo alle schede di interfaccia di rete Intel.

             #command to get pre-set maximums
             ethtool -l eth0 
             #note the pre-set "Combined" maximum value. let's consider for this example, it is 8.
             #command to combine the queues with the value reported in the pre-set "Combined" maximum value:
             ethtool -L eth0 combined 8
             #you can verify the setting using the command below
             ethtool -l eth0
    
  5. Uso dell'affinità IRQ della porta NIC. Per ottenere le prestazioni previste modificando l'affinità IRQ, prendere in considerazione alcuni parametri importanti, ad esempio la gestione di Linux della topologia del server, lo stack di driver NIC, le impostazioni predefinite e l'impostazione di irqbalance. Le ottimizzazioni delle impostazioni di affinità IRQ della porta NIC vengono eseguite con la conoscenza della topologia del server, disabilitando l'irqbalance e usando le impostazioni specifiche del fornitore della scheda di interfaccia di rete.

    Di seguito è riportato un esempio di infrastruttura di rete specifica di Mellanox per spiegare la configurazione. Per altre informazioni, vedere Strumenti di ottimizzazione delle prestazioni per schede di rete Mellanox. Si noti che i comandi cambieranno in base all'ambiente. Per altre indicazioni, contattare il fornitore della scheda di interfaccia di rete:

             #disable irqbalance or get a snapshot of the IRQ settings and force the daemon to exit
             systemctl disable irqbalance.service
             #or
             irqbalance --oneshot
    
             #download the Mellanox mlnx tools -- see https://support.mellanox.com/s/article/MLNX2-117-2523kn
    
             #be sure, common_irq_affinity.sh is executable. if not, 
             #chmod +x common_irq_affinity.sh       
    
             #display IRQ affinity for Mellanox NIC port; e.g eth0
             ./show_irq_affinity.sh eth0
    
             #optimize for best throughput performance with a Mellanox tool
             ./mlnx_tune -p HIGH_THROUGHPUT
    
             #set hardware affinity to the NUMA node hosting physically the NIC and its port
             ./set_irq_affinity_bynode.sh `\cat /sys/class/net/eth0/device/numa_node` eth0
    
             #verify IRQ affinity
             ./show_irq_affinity.sh eth0
    
             #add IRQ coalescing optimizations
             ethtool -C eth0 adaptive-rx off
             ethtool -C eth0 adaptive-tx off
             ethtool -C eth0  rx-usecs 750 tx-frames-irq 2048
    
             #verify the settings
             ethtool -c eth0
    
  6. Al termine delle 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 aggiuntiva avanzata del kernel/sistema operativo

  • Per ottimizzare le prestazioni di I/O di archiviazione, è consigliabile usare la pianificazione a più code di Linux per i dispositivi a blocchi, che rende le prestazioni a livello di blocco facilmente scalabili in base alle unità SSD e ai sistemi multicore. 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é l'I/O multipath viene spesso usato per le distribuzioni di SQL Server, anche la destinazione multicoda del mapper (DM) del dispositivo deve essere configurata per usare l'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 indicazioni aggiuntive su come configurarla, vedere la documentazione della distribuzione di Linux in uso.

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

È consigliabile 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

    È consigliabile 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ù 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.

Passaggi successivi

Per altre informazioni sulle funzionalità di SQL Server che migliorano le prestazioni, vedere Introduzione alle funzionalità relative alle prestazioni.

Per altre informazioni su SQL Server in Linux, vedere Panoramica di SQL Server in Linux.