Compartir vía

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

  • Artículo

Se aplica a: SQL Server - Linux

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

Información general

SQL Server 2019 (15.x) presentó muchas características en memoria que usan la memoria persistente. En este artículo se describen los pasos necesarios para configurar la memoria persistente para SQL Server en Linux.

Nota

El término habilitación se incluyó para transmitir el concepto de trabajar con un sistema de archivos con reconocimiento de memoria persistente. Se facilita acceso directo al sistema de archivos desde aplicaciones de espacio de usuario mediante la asignación de memoria (mmap()). Cuando se crea una asignación de memoria para un archivo, la aplicación puede emitir instrucciones de carga o almacenamiento que omiten por completo la pila de E/S. Esto se considera un método de acceso a archivos "habilitado" desde la perspectiva de la aplicación de extensión de host (que es el código que permite a SQLPAL interactuar con el sistema operativo Windows o Linux).

Creación de espacios de nombres para dispositivos PMEM

Configuración de los dispositivos

En Linux, use la utilidad ndctl.

  • Instale ndctl para configurar el dispositivo PMEM. Puede encontrarlo aquí.
  • Use ndctl para crear un espacio de nombres. Los espacios de nombres se intercalan en NVDIMMs 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

Se ha elegido el modo fsdax y se está usando la memoria del sistema para almacenar los metadatos por página. Recomendamos para ello usar --map=dev. Esta opción almacena directamente los metadatos en el espacio de nombres. El almacenamiento de metadatos en memoria mediante --map=mem es experimental en este momento.

Use 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

  • Bloquee la asignación de 2 MB para XFS/EXT4, como se describió 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).

Una vez que el dispositivo se haya configurado con ndctl, creado y montado, puede colocar archivos de base de datos en él o crear una base de datos.

Puede almacenar los archivos de datos de SQL Server (MDFS, NDFS) y tempdb en un dispositivo PMEM cuando se configura con el modo fsdax mediante el comando siguiente. No lo use para almacenar los archivos de registro de SQL Server (LDFS), ya que el registro de transacciones debe estar en un almacenamiento que proporcione garantías atómicas de sector:

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 obtener el mejor rendimiento en el acceso y la actualización de estas entradas de página NVDIMM para este dispositivo, es preferible usar -map=mem.
  • Si la capacidad de la NVDIMM es demasiado grande (más de 512 GB), establezca –map=dev, lo que afectaría al rendimiento de E/S y obstaculizaría el rendimiento.

Para los archivos de registro de SQL Server en los dispositivos PMEM, aprovisione los dispositivos PMEM para utilizar la tabla de traslación de bloques (BTT) o sectores. Esto proporciona la atomicidad de sectores necesaria para los archivos de registro de SQL Server para esta tecnología de dispositivos de almacenamiento. También se recomienda realizar validaciones de rendimiento de carga de trabajo. Puede comparar el rendimiento del registro de SQL Server para su carga de trabajo entre esta solución y las mejores unidades SSD NVMe de su clase, y luego seleccione la solución que mejor se adapte a sus necesidades y proporcione un mejor rendimiento.

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

Deshabilitación del comportamiento de vaciado forzado

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

Nota:

Un sistema de almacenamiento puede asegurarse de que las escrituras almacenadas en caché o almacenadas provisionalmente se consideren seguras y duraderas, garantizando que las escrituras emitidas al dispositivo se mantienen en un medio que persistirá a pesar de los bloqueos del sistema, los restablecimientos de la interfaz y los errores de alimentación, y que el propio medio es redundante en 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 marca de seguimiento 3979 deshabilita el uso del comportamiento de vaciado forzado para los archivos de registro de transacciones y de base de datos, y usa la lógica writethrough y alternatewritethrough.

  • Otros archivos que se abren mediante FILE_FLAG_WRITE_THROUGH en SQL Server, como instantáneas de base de datos, instantáneas internas para comprobaciones de coherencia de base de datos (DBCC CHECKDB), archivos de seguimiento del generador de perfiles y archivos de seguimiento de eventos extendidos, usan las optimizaciones writethrough y alternatewritethrough.

Para obtener más información sobre los cambios introducidos en SQL Server 2017 (14.x) CU 6, consulte KB 4131496. Para obtener 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)

Ciertas versiones de distribuciones de Linux admitidas proporcionan compatibilidad con la funcionalidad de subsistema de E/S de FUA, lo que proporciona durabilidad de datos. SQL Server usa la funcionalidad FUA para proporcionar E/S de gran eficacia y confiabilidad para las cargas de trabajo de SQL Server. Para obtener más información sobre la compatibilidad de FUA con la distribución de Linux y su efecto en SQL Server, consulte: SQL Server en Linux: Funcionamiento interno del acceso de unidad forzada (FUA).

SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 y Ubuntu 18.04 introdujeron la compatibilidad con la funcionalidad FUA en el subsistema de E/S. Si utiliza SQL Server 2017 (14.x) CU6 y versiones posteriores, debe usar la siguiente configuración para una implementación de E/S eficaz y de alto rendimiento con FUA mediante SQL Server.

Use la 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)

  • Sistema de archivos XFS para el almacenamiento de SQL Server

  • Subsistema de almacenamiento o hardware que admite y está configurado para la funcionalidad de FUA

Configuración recomendada:

  1. Habilite la marca de seguimiento 3979 como parámetro de inicio.

  2. 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, la configuración recomendada es la siguiente:

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

  2. Use mssql-conf para configurar control.writethrough = 1 y control.alternatewritethrough = 1.

Compatibilidad de FUA con contenedores de SQL Server implementados en Kubernetes

  1. El servidor SQL Server debe usar el almacenamiento montado persistente, no overlayfs.

  2. El almacenamiento debe usar el sistema de archivos XFS y debe admitir FUA. Antes de habilitar esta opción, debe trabajar con el proveedor de almacenamiento y distribución de Linux para asegurarse de que el sistema operativo y el subsistema de almacenamiento admiten 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.

  3. El nodo de trabajo que hospeda los pods de SQL Server debe usar 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).

Si se cumplen las condiciones anteriores, puede usar la siguiente configuración de FUA recomendada.

  1. Habilite la marca de seguimiento 3979 como parámetro de inicio.

  2. Use mssql-conf para configurar control.writethrough = 1 y control.alternatewritethrough = 0.

Contenido relacionado