Condividi tramite

Configurare la memoria persistente per SQL Server in Linux

  • Articolo

Si applica a: SQL Server - Linux

Questo articolo descrive come configurare la memoria persistente per SQL Server 2019 (15.x) e versioni successive in Linux.

Panoramica

SQL Server 2019 (15.x) ha introdotto molte funzionalità in memoria che usano la memoria persistente. In questo articolo vengono illustrati i passaggi necessari per configurare la memoria persistente per SQL Server in Linux.

Nota

Il termine consapevolezza è stato usato per spiegare il concetto relativo all'uso di un file system in grado di riconoscere la memoria persistente. L'accesso diretto al file system dalle applicazioni dello spazio utente viene facilitato tramite il mapping di memoria (mmap()). Quando viene creato un mapping di memoria per un file, l'applicazione può eseguire istruzioni di caricamento/archiviazione che ignorano completamente lo stack di I/O. Questo è considerato un metodo di accesso ai file "consapevole" dal punto di vista dell'applicazione dell'estensione host (ovvero il codice che consente a SQLPAL di interagire con il sistema operativo Windows o Linux).

Creare spazi dei nomi per i dispositivi con memoria persistente

Configurare i dispositivi

In Linux usare l'utilità ndctl.

  • Installare ndctl per configurare il dispositivo con memoria persistente. L'utilità è disponibile qui.
  • Usare ndctl per creare uno spazio dei nomi. Gli spazi dei nomi sono interfoliati tra i moduli NVDIMM di memoria persistente e possono offrire diversi tipi di accesso dello spazio utente alle aree di memoria sul dispositivo. fsdax è la modalità predefinita e desiderata per SQL Server.
ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

È stata scelta la modalità fsdax e viene usata la memoria di sistema per archiviare i metadati per pagina. Ti consigliamo di usare --map=dev. Con questa opzione, i metadati vengono archiviati direttamente nello spazio dei nomi. L'archiviazione dei metadati in memoria tramite --map=mem è al momento sperimentale.

Usare ndctl per verificare lo spazio dei nomi.

Di seguito è riportato output di esempio:

# ndctl list -N
{
  "dev":"namespace0.0",
  "mode":"fsdax",
  "map":"dev",
  "size":4294967296,
  "sector_size":512,
  "blockdev":"pmem0",
  "numa_node":0
}

Creare e montare il dispositivo con memoria persistente

Ad esempio, con XFS

mkfs.xfs -f /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax
xfs_io -c "extsize 2m" /mnt/dax

Ad esempio, con EXT4

mkfs.ext4 -b 4096 -E stride=512 -F /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax

Considerazioni tecniche

  • Bloccare l'allocazione di 2 MB per XFS/EXT4, come descritto in precedenza
  • Il mancato allineamento tra l'allocazione dei blocchi e mmap ha come risultato il fallback invisibile a 4 KB
  • Le dimensioni dei file devono essere un multiplo di 2 MB (modulo 2 MB)
  • Non disabilitare le pagine di tipo THP (Transparent Huge Page) (abilitate per impostazione predefinita nella maggior parte delle distribuzioni)

Dopo che il dispositivo è stato configurato con ndctl, formattato e montato, è possibile inserirvi i file di database oppure creare un nuovo database.

È possibile archiviare i file di dati SQL Server (MDFS, NDFS) e tempdb in un dispositivo PMEM configurato con la modalità fsdax usando il comando seguente. Non usarlo per archiviare i file di log (LDFS) di SQL Server, perché il log delle transazioni deve trovarsi in una risorsa di archiviazione che fornisce garanzie atomiche del settore:

ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

Prima di impostare l'opzione map nel comando precedente, tenere presente quanto segue:

  • Per ottenere prestazioni ottimali per l'accesso e l'aggiornamento di queste voci di pagina NVDIMM per il dispositivo, è preferibile usare -map=mem
  • Se la capacità del dispositivo NVDIMM è eccessiva (superiore a 512 GB), impostare –map=dev, che inciderebbe sulla velocità effettiva di I/O e sulle prestazioni

Per i file di log di SQL Server nei dispositivi PMEM, effettuare il provisioning dei dispositivi PMEM per l'uso di sector/Block Translation Table (BTT). Ciò garantisce l'atomicità del settore necessaria per i file di log di SQL Server per questa tecnologia di dispositivi di archiviazione. Si consiglia inoltre di eseguire le convalide delle prestazioni del carico di lavoro. È anche consigliabile eseguire convalide delle prestazioni del carico di lavoro e confrontare le prestazioni del log di SQL Server per il carico di lavoro tra questa soluzione e le migliori unità SSD NVMe e quindi selezionare la soluzione più adatta alle proprie esigenze e che offre prestazioni migliori.

ndctl create-namespace -f -e namespace0.0 --mode= sector

Disabilitare il comportamento di scaricamento forzato

Poiché i dispositivi PMEM sono O_DIRECT sicuri (I/O diretti), è possibile disabilitare il comportamento di scaricamento forzato.

Nota

Un sistema di archiviazione può assicurarsi che tutte le scritture memorizzate nella cache o in gestione temporanea siano considerate sicure e durevoli, garantendo che le scritture rilasciate nel dispositivo vengano conservate su un supporto con salvataggio permanente tra arresti anomali del sistema, reimpostazioni dell'interfaccia e interruzioni dell'alimentazione e il supporto stesso ha hardware ridondante.

  • I file del database (.mdf e .ndf) e del log delle transazioni (.ldf) non usano writethrough e alternatewritethrough per impostazione predefinita in SQL Server 2017 (14.x) CU 6 e versioni successive, perché usano il comportamento di scaricamento forzato. Il flag di traccia 3979 disabilita l'uso del comportamento di scaricamento forzato per i file di database e di log delle transazioni e usa la logica writethrough e alternatewritethrough.

  • Altri file aperti tramite FILE_FLAG_WRITE_THROUGH in SQL Server, ad esempio snapshot del database, snapshot interni per i controlli di coerenza del database (DBCC CHECKDB), file di traccia del profiler e file di traccia degli eventi estesi, usano le ottimizzazioni writethrough e alternatewritethrough.

Per altre informazioni sulle modifiche introdotte in SQL Server 2017 (14.x) CU 6, vedere KB 4131496. Per altre informazioni sugli elementi interni dell'accesso forzato (FUA), vedere FUA internals.

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.

Contenuto correlato