Configuración de la memoria persistente (PMEM) para SQL Server en Linux

Se aplica a:SQL Server en Linux

Este artículo describe cómo configurar la memoria persistente (PMEM) para SQL Server 2019 (15.x) y versiones posteriores en Linux.

Visión general

SQL Server 2019 (15.x) añade soporte de memoria persistente para acelerar varias operaciones que requieren mucho almacenamiento.

Con un sistema de archivos compatible con PMEM, el mapeo de memoria (mmap()) da a las aplicaciones en espacio de usuario acceso directo a los datos de los archivos. Cuando se crea un mapa de memoria para un archivo, la aplicación puede emitir instrucciones de carga/almacenamiento que saltan la capa de almacenamiento.

Note

Este acceso directo se denomina método de acceso a archivos iluminado desde la perspectiva de la aplicación de extensión anfitriona, que es la forma en que SQL Server interactúa con el sistema operativo anfitrión, utilizando la Capa de Abstracción de la Plataforma SQL (SQLPAL).

Este artículo te muestra cómo configurar la memoria persistente para SQL Server en Linux.

Crear espacios de nombres para dispositivos PMEM

Configuración de los dispositivos

En Linux, use la utilidad ndctl.

Instale ndctl para configurar el dispositivo PMEM a partir de Instalación de NDCTL.
Utilice ndctl para crear un espacio de nombres. Los espacios de nombres se intercalan en NVDIMM de PMEM y pueden proporcionar diferentes tipos de acceso de espacio de usuario a las regiones de memoria del dispositivo. fsdax es el modo predeterminado y el modo deseado para SQL Server.

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

El fsdax modo almacena metadatos por página en la memoria del sistema. Se recomienda esta --map=dev opción porque almacena los metadatos directamente en el espacio de nombres. Almacenar metadatos en memoria con --map=mem es experimental.

Utilice ndctl para comprobar el espacio de nombres.

La salida de ejemplo es la siguiente:

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

Creación y montaje del dispositivo PMEM

Por ejemplo, con XFS:

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

Por ejemplo, con ext4:

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

Consideraciones técnicas

Asignación de bloques de 2 MB para XFS o ext4, como se ha descrito anteriormente.
La alineación incorrecta entre la asignación de bloques y mmap da como resultado un retorno silencioso a 4 KB.
Los tamaños de archivo deben ser un múltiplo de 2 MB (módulo de 2 MB).
No deshabilite páginas de gran tamaño transparentes (THP) (habilitadas de forma predeterminada en la mayoría de distribuciones).

Después de configurar ndctl , crear y montar el dispositivo, puedes colocar archivos de base de datos en él o crear una nueva.

Puedes almacenar los archivos de datos de SQL Server (.mdf, .ndf) y tempdb archivos en un dispositivo PMEM en fsdax modo con el siguiente comando. No uses este modo para almacenar los archivos de registro de SQL Server (.ldf), porque el registro de transacciones requiere almacenamiento que proporcione garantías atómicas sectoriales:

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

Antes de establecer la opción de mapa en el comando anterior, tenga en cuenta los siguientes puntos:

Para un mejor rendimiento al acceder y actualizar estas entradas de página NVDIMM para este dispositivo, utilice -map=mem
Si la capacidad del NVDIMM es demasiado grande (superior a 512 GB), se establece -map=dev, lo que afecta al rendimiento de E/S y reduce el rendimiento

Para archivos de registro de SQL Server en dispositivos PMEM, configura los dispositivos PMEM para que utilicen la Tabla de Traducción de Sector/Bloque (BTT). Esta configuración proporciona la atomicidad sectorial que los archivos de registro de SQL Server requieren para esta tecnología de almacenamiento. Realizar validaciones de rendimiento de carga de trabajo. Compara el rendimiento de los registros de SQL Server para tu carga de trabajo entre esta solución y los mejores SSD NVMe, y luego selecciona el que mejor se adapte a tus necesidades.

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

Deshabilitar el comportamiento de vaciado forzoso

Dado que los dispositivos PMEM son seguros respecto a O_DIRECT (E/S directa), puede deshabilitar el comportamiento de vaciado forzado.

Note

Un sistema de almacenamiento puede garantizar que cualquier escritura en caché o por etapas sea segura y duradera asegurando que las escrituras en el dispositivo residan en un medio que persista a través de fallos del sistema, reinicios de interfaz y cortes de energía, y que el propio medio sea redundante por hardware.

Los archivos de base de datos (.mdf y .ndf) y del registro de transacciones (.ldf) no usan writethrough yalternatewritethrough, de forma predeterminada en SQL Server 2017 (14.x) CU 6 y versiones posteriores, ya que usan el comportamiento de vaciado forzado. La bandera de traza 3979 desactiva el comportamiento de vaciado forzado para archivos de registro de bases de datos y transacciones, y utiliza la writethrough lógica de and alternatewritethrough .
Otros archivos que SQL Server abre con FILE_FLAG_WRITE_THROUGH, como instantáneas de base de datos, instantáneas internas para comprobaciones de consistencia de base de datos (DBCC CHECKDB), archivos de traza de perfiladores y archivos de rastreo de eventos extendidos, utilizan las writethrough optimizaciones de y alternatewritethrough .

Para obtener más información sobre los cambios introducidos en SQL Server 2017 (14.x) CU 6, consulte KB 4131496. Para más información sobre los elementos internos de acceso a unidades forzadas (FUA), consulte Elementos internos de FUA.

Funcionalidad del subsistema de E/S de SQL Server y acceso de unidad forzada (FUA)

Algunas distribuciones de Linux admitidas implementan el acceso a unidades forzadas (FUA) en el nivel de subsistema de E/S para garantizar la durabilidad de los datos. SQL Server aprovecha esta funcionalidad para proporcionar un rendimiento de E/S eficaz y confiable para cargas de trabajo de Linux. Para obtener más información sobre la compatibilidad con FUA en distribuciones de Linux y su efecto en SQL Server, consulte SQL Server en Linux: Forced Unit Access (FUA) Internals.

La compatibilidad con FUA en el subsistema de E/S se introdujo en SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 y Ubuntu 18.04. En SQL Server 2017 (14.x) CU 6 y versiones posteriores, use la siguiente configuración para habilitar E/S de alto rendimiento y eficiente con FUA en SQL Server.

Use esta configuración recomendada si se cumplen las condiciones siguientes:

SQL Server 2017 (14.x) CU6 y versiones posteriores
Una distribución y una versión de Linux que admiten la funcionalidad de FUA (a partir de Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 o Ubuntu 18.04)

Note

A partir de SQL Server 2025 (17.x), no se admite SUSE Linux Enterprise Server (SLES).
Sistema de archivos XFS para el almacenamiento de SQL Server, en el kernel de Linux 4.18 o versiones posteriores.
sistema de archivos ext4 para el almacenamiento de SQL Server, en el kernel de Linux 5.6 o versiones posteriores.

Note

Use el sistema de archivos XFS para hospedar archivos de registro de transacciones y datos de SQL Server cuando la versión del kernel de Linux sea inferior a la 5.6. A partir de la versión del kernel 5.6, puede elegir entre XFS y ext4 en función de sus requisitos específicos.
Subsistema de almacenamiento y hardware que admite y está configurado para la funcionalidad FUA

Configuración recomendada:

Habilite la marca de seguimiento 3979 como parámetro de inicio.
Use mssql-conf para configurar control.writethrough = 1 y control.alternatewritethrough = 0.

Para casi todas las demás configuraciones que no cumplen las condiciones anteriores, use la siguiente configuración recomendada:

Habilite la marca de seguimiento 3982 como parámetro de inicio (que es el valor predeterminado para SQL Server en el ecosistema de Linux) y asegúrese de que la marca de seguimiento 3979 no está habilitada como parámetro de inicio.
Use mssql-conf para configurar control.writethrough = 1 y control.alternatewritethrough = 1.

Compatibilidad de FUA con contenedores de SQL Server implementados en Kubernetes

El servidor SQL Server debe usar el almacenamiento montado persistente, no overlayfs.
El almacenamiento debe usar los sistemas de archivos XFS o ext4 y debe admitir FUA (ext4 no admite FUA en el kernel de Linux anterior a la versión 5.6). Antes de habilitar esta configuración, trabaje con el proveedor de almacenamiento y distribución de Linux para asegurarse de que el sistema operativo y el subsistema de almacenamiento admiten las opciones de FUA. En Kubernetes, puede consultar el tipo de sistema de archivos mediante el siguiente comando, donde <pvc-name> es PersistentVolumeClaim:
```
kubectl describe pv <pvc-name>
```
En la salida, busque el fstype que está establecido en XFS.
El nodo de trabajo que hospeda los pods de SQL Server debe usar una distribución y versión de Linux que admita la funcionalidad FUA (a partir de Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 o Ubuntu 18.04).

Si se cumplen las condiciones anteriores, use la siguiente configuración recomendada de FUA:

Habilite la marca de seguimiento 3979 como parámetro de inicio.
Use mssql-conf para configurar control.writethrough = 1 y control.alternatewritethrough = 0.

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2026-08-14