Compartir vía

Procedimientos recomendados de rendimiento e instrucciones de configuración para SQL Server en Linux

Se aplica a:SQL Server en Linux

En este artículo se ofrecen procedimientos recomendados y recomendaciones para maximizar el rendimiento de las aplicaciones de base de datos que se conectan a SQL Server en Linux. Estas recomendaciones son específicas para la ejecución en la plataforma Linux. Se siguen aplicando todas las recomendaciones normales de SQL Server, como el diseño de índices.

Las instrucciones siguientes contienen recomendaciones para configurar SQL Server y el sistema operativo (SO) Linux. Considere la posibilidad de usar las siguientes opciones de configuración para obtener el mejor rendimiento para una instalación de SQL Server.

Recomendación de configuración de almacenamiento

El subsistema de almacenamiento que hospeda los datos, los registros de transacciones y otros archivos asociados (por ejemplo, los archivos de punto de comprobación para OLTP en memoria) debe ser capaz de administrar las cargas de trabajo de tipo medio y máximo correctamente.

Uso del subsistema de almacenamiento con los valores adecuados de IOPS, rendimiento y redundancia

En entornos locales, el proveedor de almacenamiento normalmente admite la configuración RAID de hardware adecuada con seccionamiento entre varios discos para garantizar la IOPS, el rendimiento y la redundancia adecuados. Sin embargo, esta compatibilidad puede diferir entre distintos proveedores de almacenamiento y diferentes ofertas de almacenamiento con distintas arquitecturas.

Para SQL Server en Linux implementado en Azure Virtual Machines, considere la posibilidad de usar RAID de software para garantizar los requisitos de rendimiento y IOPS adecuados. Al configurar SQL Server en máquinas virtuales de Azure con consideraciones de almacenamiento similares, consulte Configuración de almacenamiento para máquinas virtuales SQL Server en Azure.

En el ejemplo siguiente se muestra cómo crear software RAID en Linux en una máquina virtual de Azure. Tenga en cuenta que debe usar el número adecuado de discos de datos para los valores necesarios de rendimiento e IOPS para los volúmenes en función de los requisitos de datos, registro de transacciones y E/S de tempdb. En el ejemplo siguiente, ocho discos de datos estaban conectados a la máquina virtual; cuatro para hospedar archivos de datos, dos para los registros de transacciones y dos para la tempdb carga de trabajo.

Para buscar los dispositivos (por ejemplo, /dev/sdc) para la creación de RAID, use el 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

Recomendaciones de configuración y partición de discos

Para SQL Server, utilice configuración RAID. La unidad de franja del sistema de archivos implementada (sunit) y el ancho de franja coinciden con la geometría RAID. Por ejemplo, en el ejemplo siguiente se muestra una configuración basada en XFS para un volumen de registro.

# 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 matriz de registros es un RAID-10 de seis unidades con una franja de 64 KB. Como puede ver:

  • Para sunit=16 blks, 16 * 4096 tamaño de bloque = 64 KB, coincide con el tamaño de franja.
  • Para swidth=48 blks, swidth / sunit = 3, que es el número de unidades de datos de la matriz, excepto las unidades de paridad.

SQL Server admite sistemas de archivos ext4 y XFS para hospedar la base de datos, los registros de transacciones y otros archivos, como los archivos de punto de comprobación para OLTP en memoria en SQL Server. Use el sistema de archivos XFS para hospedar los archivos de registro de transacciones y datos de SQL Server.

Dé formato al volumen con el sistema de archivos XFS:

mkfs.xfs /dev/md0 -f -L datavolume
mkfs.xfs /dev/md1 -f -L logvolume
mkfs.xfs /dev/md2 -f -L tempdb

Puede configurar el sistema de archivos XFS para que no tenga distinción entre mayúsculas y minúsculas al crear y dar formato al volumen XFS. Esta configuración no se usa con frecuencia en el ecosistema de Linux, pero se puede usar por motivos de compatibilidad.

Por ejemplo, puede ejecutar el siguiente comando. Use -n version=ci para configurar el sistema de archivos XFS para que sea insensible a mayúsculas.

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

Recomendación del sistema de archivos de memoria persistente

Para la configuración del sistema de archivos en dispositivos de memoria persistente, establezca la asignación de bloques para el sistema de archivos subyacente en 2 MB. Para obtener más información, consulte Consideraciones técnicas.

Limitación de archivo abierto

El entorno de producción puede requerir más conexiones que el límite de archivos abiertos predeterminado de 1024. Puede establecer límites suaves y duros en 1.048.576. Por ejemplo, en RHEL, edite el archivo /etc/security/limits.d/99-mssql-server.conf para que tenga los valores siguientes:

mssql - nofile 1048576

Nota

Esta configuración no se aplica a los servicios de SQL Server iniciados por systemd. Para obtener más información, consulte Cómo establecer límites para los servicios en RHEL y systemd.

Deshabilitar la fecha y hora de acceso por última vez en los sistemas de archivos para los archivos de datos y de registro de SQL Server.

Para asegurarse de que las unidades conectadas al sistema se vuelvan a montar automáticamente después de un reinicio, agréguelas al /etc/fstab archivo. Use el UUID (Identificador único universal) en /etc/fstab para hacer referencia a la unidad, en lugar de simplemente el nombre del dispositivo (como /dev/sdc1).

Use el atributo noatime con cualquier sistema de archivos que se almacene archivos de datos y de registro de SQL Server. Consulte la documentación de Linux para obtener información sobre cómo establecer este atributo. En el siguiente ejemplo se muestra cómo habilitar la opción noatime para un volumen montado en una máquina virtual Azure.

Entrada del punto de montaje en /etc/fstab:

UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" /data1 xfs rw,attr2,noatime 0 0

En el ejemplo anterior, UUID representa el dispositivo que se puede encontrar mediante el comando blkid.

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

    Nota

    Debe usar 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 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 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 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.

Configuración del kernel y la CPU para alto rendimiento

En la sección siguiente se describe la configuración recomendada del sistema operativo Linux relacionada con el alto rendimiento de una instalación de SQL Server. Vea la documentación de la distribución de Linux para obtener información sobre el proceso de configuración de estas opciones. Puede usar TuneD como se describe para configurar muchas CPU y configuraciones de kernel, que se describen en la sección siguiente.

Uso de Optimizado para configurar las opciones del kernel

Para los usuarios de Red Hat Enterprise Linux (RHEL), el perfil de rendimiento de TuneD configura automáticamente algunas opciones de kernel y CPU (excepto los estados de C). A partir de RHEL 8.0, se ha desarrollado un perfil Optimizado denominado mssql conjuntamente con Red Hat. Ofrece optimizaciones relacionadas con el rendimiento de Linux más precisas para cargas de trabajo de SQL Server. Este perfil incluye el perfil de rendimiento de RHEL, y a continuación se presentan sus definiciones en este artículo para que las revise con otras distribuciones de Linux y versiones de RHEL sin este perfil.

Para SUSE Linux Enterprise Server 12 SP5, Ubuntu 18.04 y Red Hat Enterprise Linux 7.x, puede instalar manualmente el tuned paquete. Úselo para crear y configurar el mssql perfil como se describe en la sección siguiente.

Configuración propuesta de Linux mediante un perfil Optimizado mssql

En el ejemplo siguiente se proporciona una configuración de TuneD para SQL Server en 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

Si usa distribuciones Linux con versiones del kernel superiores a 4.18, comente las siguientes opciones tal y como se muestran; en caso contrario, descomente las siguientes opciones si usa distribuciones con versiones del kernel anteriores a 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

Para habilitar este perfil Optimizado, guarde estas definiciones en un archivo tuned.conf en la carpeta /usr/lib/tuned/mssql y habilite el perfil mediante los comandos siguientes:

chmod +x /usr/lib/tuned/mssql/tuned.conf
tuned-adm profile mssql

Compruebe que el perfil está activo, con el siguiente comando:

tuned-adm active

O:

tuned-adm list

Recomendación de configuración de CPU

En la tabla siguiente se proporcionan recomendaciones para la configuración de la CPU:

Configuración Importancia Más información
Regulador de frecuencia de CPU rendimiento Consulte el comando cpupower.
ENERGY_PERF_BIAS rendimiento Consulte el comando x86_energy_perf_policy.
min_perf_pct 100 Consulte la documentación sobre Intel P-state
C-States Solo C1 Consulte la documentación del sistema o de Linux para saber cómo asegurarse de que C-States solo se establece en C1

Cuando uses TuneD como se describe, automáticamente configura el regulador de frecuencia del procesador, ENERGY_PERF_BIAS y min_perf_pct. Usa el perfil de rendimiento como base para el mssql perfil. Debe configurar manualmente el parámetro C-States según la documentación proporcionada por Linux o el distribuidor del sistema.

Recomendaciones de configuración de disco

En la tabla siguiente se proporcionan recomendaciones para la configuración del disco:

Configuración Importancia Más información
Disco readahead 4096 Consulte para el comando blockdev
Configuración de 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		 Consulte el comando sysctl.

Descripción

  • vm.swappiness: Este parámetro controla el peso relativo dado para intercambiar la memoria de proceso en tiempo de ejecución en comparación con la caché del sistema de archivos. El valor predeterminado de este parámetro es 60, que indica el intercambio de páginas de memoria del proceso en tiempo de ejecución en comparación con la eliminación de páginas de caché del sistema de archivos con una proporción de 60:140. Establecer el valor en 1 indica una preferencia fuerte para mantener la memoria del proceso en tiempo de ejecución en la memoria física a costa de la memoria caché del sistema de archivos. Dado que SQL Server utiliza el grupo de búferes como caché de páginas de datos y prefiere firmemente escribir directamente en el hardware físico, evitando la caché del sistema de archivos para garantizar una recuperación confiable, una configuración agresiva de intercambio puede ser beneficiosa para SQL Server dedicado y de alto rendimiento.

    Puede encontrar información adicional en Documentación de /proc/sys/vm/ - #swappiness.

  • vm.dirty_*: los accesos de escritura de archivos de SQL Server no están almacenados en caché, lo que satisface sus requisitos de integridad de datos. Estos parámetros permiten un rendimiento de escritura asincrónico eficaz y reducen el efecto de la E/S de almacenamiento de las escrituras de almacenamiento en caché de Linux al permitir un almacenamiento en caché suficientemente grande mientras se limita el vaciado.

  • kernel.sched_*: estos valores de parámetro representan la recomendación actual para ajustar el algoritmo De programación completamente justa (CFS) en el kernel de Linux. Mejoran el rendimiento de las llamadas de E/S de red y almacenamiento en relación con la preempción y reanudación de subprocesos entre procesos.

Con el perfil TuneD se configuran los ajustes mssql, vm.swappiness y vm.dirty_*. Debe configurar manualmente la configuración del disco readahead mediante el blockdev comando para cada dispositivo.

Configuración del kernel para el ajuste automático de NUMA en sistemas NUMA multinodo

Si instala SQL Server en un sistema NUMA de varios nodos, la siguiente kernel.numa_balancing configuración del kernel está habilitada de forma predeterminada. Para permitir que SQL Server funcione con la máxima eficacia en un sistema NUMA, deshabilite el equilibrio de NUMA automático en un sistema NUMA multinodo:

sysctl -w kernel.numa_balancing=0

El uso del perfil Optimizado mssql configura la opción kernel.numa_balancing.

Configuración del kernel para el espacio de direcciones virtuales

Es posible que la configuración predeterminada de vm.max_map_count (que es 65536) no sea lo suficientemente alta para una instalación SQL Server. Por este motivo, cambie el valor de vm.max_map_count a 262144 como mínimo para una implementación de SQL Server y consulte la sección Configuración propuesta de Linux mediante un perfil Optimizado mssql para realizar ajustes adicionales en estos parámetros de kernel. El valor máximo de vm.max_map_count es 2147483647.

sysctl -w vm.max_map_count=1600000

El uso del perfil Optimizado mssql configura la opción vm.max_map_count.

Habilitación de Transparent Huge Pages (THP)

La mayoría de las instalaciones de Linux tienen esta opción de forma predeterminada. Para obtener la experiencia de rendimiento más coherente, deje habilitada esta opción de configuración. Sin embargo, si hay mucha actividad de paginación de memoria en implementaciones de SQL Server con varias instancias o ejecución de SQL Server con otras aplicaciones exigentes de memoria en el servidor, pruebe el rendimiento de la aplicación después de ejecutar el siguiente comando:

echo madvise > /sys/kernel/mm/transparent_hugepage/enabled

O modifique el perfil Optimizado mssql con la línea:

vm.transparent_hugepages=madvise

Y asegúrese de que el mssql perfil está activo después de la modificación:

tuned-adm off
tuned-adm profile mssql

El uso del perfil Optimizado mssql configura la opción transparent_hugepage.

Recomendaciones de configuración de red

Además de las recomendaciones de almacenamiento y CPU, también tiene recomendaciones específicas de red. Se muestran las siguientes recomendaciones como referencia. No todas las opciones de configuración de los ejemplos siguientes están disponibles en diferentes NIC. Consulte a los proveedores de NIC si quiere obtener instrucciones para cada una de estas opciones. Pruebe y configure esto en entornos de desarrollo antes de aplicarlas en entornos de producción. Las opciones que se mencionan a continuación se explican con ejemplos y los comandos que se usan son específicos del tipo de NIC y del proveedor.

  1. Configuración del tamaño de búfer del puerto de red. En el ejemplo, la NIC se denomina eth0, que es una NIC basada en Intel. En el caso de la NIC basada en Intel, el tamaño de búfer recomendado es de 4 KB (4096). Compruebe los valores máximos establecidos previamente y, después, configúrelos con el ejemplo siguiente:

    Compruebe los valores máximos preestablecidos con el comando siguiente. Reemplace eth0 por el nombre de la NIC:

    ethtool -g eth0

    Establezca el tamaño de búfer de rx (recepción) y tx (transmisión) en 4 KB:

    ethtool -G eth0 rx 4096 tx 4096

    Compruebe que el valor esté configurado correctamente:

    ethtool -g eth0

  2. Habilitación de marcos gigantes. Antes de habilitar los marcos gigantes, compruebe que todos los conmutadores de red, los enrutadores y los demás elementos esenciales de la ruta del paquete de red entre los clientes y SQL Server los admiten. Solo entonces puede habilitar fotogramas jumbo para mejorar el rendimiento. Una vez habilitados los marcos de jumbo, conéctese a SQL Server y cambie el tamaño del paquete de red a 8060 mediante sp_configure, como se muestra en el ejemplo siguiente:

    # 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

    EXECUTE sp_configure 'network packet size', '8060';
GO

RECONFIGURE WITH OVERRIDE;
GO

  3. De forma predeterminada, configure el puerto para la coalescencia adaptativa de IRQ para RX/TX, lo que significa que las interrupciones se ajustan para mejorar la latencia cuando la tasa de paquetes es baja y mejorar el rendimiento de transferencia cuando la tasa de paquetes es alta. Es posible que esta configuración no esté disponible en la infraestructura de red, por lo que debe revisar la infraestructura de red existente y confirmar que esta configuración es compatible. El ejemplo es para la NIC denominada eth0, que es una NIC basada en Intel:

    1. Establezca el puerto para la fusión de IRQ de RX/TX adaptable:

      ethtool -C eth0 adaptive-rx on
ethtool -C eth0 adaptive-tx on

    2. Confirme la configuración:

      ethtool -c eth0

    Nota

    Para un comportamiento predecible en entornos de alto rendimiento, como los entornos para realizar pruebas comparativas, deshabilite la coherencia de IRQ RX/TX adaptable y, a continuación, establezca específicamente la coherencia de interrupciones RX/TX. Vea los comandos de ejemplo para deshabilitar la fusión de IRQ de RX/TX y, después, establezca los valores específicamente:

    Deshabilite la fusión de IRQ de RX/TX IRQ adaptable:

    ethtool -C eth0 adaptive-rx off
ethtool -C eth0 adaptive-tx off

    Confirme el cambio:

    ethtool -c eth0

    Establezca los parámetros rx-usecs y irq. rx-usecs especifica cuántos microsegundos deben pasar después de recibir al menos un paquete para generar una interrupción. El parámetro irq especifica los retrasos correspondientes al actualizar el estado cuando se deshabilita la interrupción. En el caso de las NIC basadas en Intel, puede usar la siguiente configuración:

    ethtool -C eth0 rx-usecs 100 tx-frames-irq 512

    Confirme el cambio:

    ethtool -c eth0

  4. Habilite el escalado en el lado de recepción (RSS) y, de forma predeterminada, combine el lado RX y TX de las colas RSS. Hay escenarios específicos, al trabajar con el soporte técnico de Microsoft, donde deshabilitar RSS también mejora el rendimiento. Pruebe esta configuración en entornos de prueba antes de aplicarla en entornos de producción. En el ejemplo siguiente se usan las NIC de Intel.

    Obtenga los valores máximos predefinidos:

    ethtool -l eth0

    Combine las colas con el valor notificado en el valor máximo "Combinado" predefinido. En este ejemplo, el valor está establecido en 8:

    ethtool -L eth0 combined 8

    Compruebe la configuración:

    ethtool -l eth0

  5. Trabaje con la afinidad IRQ del puerto NIC. Para lograr el rendimiento esperado mediante el ajuste de la afinidad IRQ, tenga en cuenta algunos parámetros importantes, entre los que se incluyen el control de Linux de la topología del servidor, la pila de controladores NIC, la configuración predeterminada y la configuración irqbalance. Las optimizaciones de la configuración de afinidades IRQ del puerto NIC se realizan con el conocimiento de la topología del servidor, deshabilitando el irqbalance y utilizando los ajustes específicos del proveedor de la NIC.

    El ejemplo siguiente de infraestructura de red específica de Mellanox facilita la explicación de la configuración. Para obtener más información y descargar las herramientas de mlnx de Mellanox, consulte Herramientas de ajuste de rendimiento para adaptadores de red Mellanox. Los comandos cambian en función del entorno. Póngase en contacto con el proveedor de la NIC para obtener instrucciones adicionales.

    Deshabilite irqbalance u obtenga una instantánea de la configuración de IRQ y fuerce la salida del demonio:

    systemctl disable irqbalance.service

    O:

    irqbalance --oneshot

    Asegúrese de que common_irq_affinity.sh es ejecutable:

    chmod +x common_irq_affinity.sh

    Muestre la afinidad de IRQ para el puerto de NIC de Mellanox (por ejemplo, eth0):

    ./show_irq_affinity.sh eth0

    Optimice para lograr el mejor rendimiento con una herramienta de Mellanox:

    ./mlnx_tune -p HIGH_THROUGHPUT

    Establezca la afinidad de hardware con el nodo NUMA que hospeda físicamente la NIC y su puerto:

    ./set_irq_affinity_bynode.sh `\cat /sys/class/net/eth0/device/numa_node` eth0

    Compruebe la afinidad de IRQ:

    ./show_irq_affinity.sh eth0

    Agregue las optimizaciones de fusión de IRQ

    ethtool -C eth0 adaptive-rx off
ethtool -C eth0 adaptive-tx off
ethtool -C eth0  rx-usecs 750 tx-frames-irq 2048

    Compruebe la configuración:

    ethtool -c eth0

  6. Después de realizar los cambios anteriores, compruebe la velocidad de la NIC para asegurarse de que cumple sus expectativas mediante el siguiente comando:

    ethtool eth0 | grep -i Speed

Configuración avanzada del kernel y del sistema operativo

  • Para obtener el mejor rendimiento de E/S de almacenamiento, use la programación de varias colas de Linux para dispositivos bloqueados. Este método de programación permite que el rendimiento de la capa de bloques se escale bien con unidades de estado sólido (SSD) rápidas y sistemas de varios núcleos. Compruebe la documentación para ver si la distribución de Linux la habilita de forma predeterminada. En la mayoría de los otros casos, puede arrancar el kernel con scsi_mod.use_blk_mq=y para habilitarlo. La documentación de la distribución de Linux puede tener más instrucciones sobre esta configuración. Esta configuración es coherente con el kernel de Linux principal.

  • Dado que la E/S de múltiples rutas se usa a menudo para las implementaciones de SQL Server, configure el destino multiqueue del asignador de dispositivos (DM) para usar la blk-mq infraestructura, habilitando la dm_mod.use_blk_mq=y opción de arranque del kernel. El valor predeterminado es n (deshabilitado). Esta configuración reduce la sobrecarga de bloqueo en la capa DM cuando los dispositivos SCSI subyacentes usan blk-mq. Para obtener más información sobre cómo configurar la E/S de múltiples rutas, consulte la documentación de la distribución de Linux.

Configuración del archivo de intercambio

Asegúrese de que tiene un archivo de intercambio configurado correctamente para evitar problemas de memoria insuficiente. Consulte la documentación de Linux para obtener información sobre cómo crear y ajustar correctamente el tamaño de un archivo de intercambio.

Máquinas virtuales y memoria dinámica

Si ejecuta SQL Server en Linux en una máquina virtual, asegúrese de seleccionar opciones para corregir la cantidad de memoria reservada para la máquina virtual. No use características como Memoria dinámica de Hyper-V.

Configuración de SQL Server

Realice las siguientes tareas de configuración después de instalar SQL Server en Linux para lograr el mejor rendimiento para la aplicación.

procedimientos recomendados

Uso de PROCESS AFFINITY en el nodo o las CPU

Utiliza ALTER SERVER CONFIGURATION para establecer PROCESS AFFINITY para todos los NUMANODEs y CPUs que usas para SQL Server (que normalmente es para todos los nodos y CPUs) en un sistema operativo Linux. La afinidad del procesador contribuye a mantener un comportamiento eficaz de programación de Linux y SQL. El uso de la opción NUMANODE es el método más sencillo. Use PROCESS AFFINITY aunque solo tenga un único nodo NUMA en el equipo. Para obtener más información sobre cómo establecer PROCESS AFFINITY, vea el artículo ALTER SERVER CONFIGURATION.

Configuración de varios archivos de datos de tempdb

Dado que una instalación de SQL Server en Linux no ofrece una opción para configurar varios archivos de tempdb, se recomienda que se plantee la posibilidad de crear varios archivos de datos de tempdb después de la instalación. Para obtener más información, consulte las instrucciones del artículo Recomendaciones para reducir la contención de asignación en la base de datos tempdb de SQL Server.

Configuración avanzada

Las siguientes recomendaciones son valores de configuración opcionales que puede ejecutar tras la instalación de SQL Server en Linux. Estas opciones se basan en los requisitos de la carga de trabajo y la configuración del sistema operativo Linux.

Establecimiento de un límite de memoria con mssql-conf

Para asegurarse de que hay suficiente memoria física libre para el sistema operativo Linux, el proceso de SQL Server usa solo 80% de la RAM física de forma predeterminada. Para algunos sistemas con grandes cantidades de RAM física, 20% podría ser un número significativo.

Por ejemplo, en un sistema con 1 TB de RAM, el valor predeterminado dejaría alrededor de 200 GB de RAM sin usar. En esta situación, es posible que quiera configurar el límite de memoria en un valor más alto. Puede ajustar este valor con la herramienta mssql-conf . Para obtener más información, vea la configuración memory.memorylimitmb que controla la memoria visible para SQL Server (en unidades de MB).

Nota

También puede configurar un límite de memoria mediante la variable de MSSQL_MEMORY_LIMIT_MB entorno. Este método se usa normalmente al implementar contenedores o automatizar implementaciones basadas en paquetes o contenedores de SQL Server. La MSSQL_MEMORY_LIMIT_MB variable de entorno tiene prioridad sobre la memory.memorylimitmb configuración.

Al cambiar esta opción, tenga cuidado de no establecer este valor demasiado alto. Si no deja memoria suficiente, podría experimentar problemas con el sistema operativo Linux y otras aplicaciones de Linux.

Configuración de límites de memoria con el grupo de control (cgroup) v2

A partir de SQL Server 2025 (17.x) y SQL Server 2022 (16.x) CU 20, SQL Server detecta y respeta las restricciones del grupo de control (cgroup) v2, lo que mejora la estabilidad del rendimiento y el aislamiento de recursos en los entornos de Docker, Kubernetes y OpenShift. Los grupos de controles permiten un control específico en el kernel de Linux a través de recursos del sistema, como CPU y memoria.

Con la compatibilidad con cgroup v2, SQL Server mitiga los errores de memoria insuficiente (OOM) observados anteriormente en implementaciones en contenedores, especialmente en clústeres de Kubernetes (por ejemplo, AKS v1.25 y versiones posteriores), donde no se aplicaron límites de memoria definidos en especificaciones de contenedor.

Comprobación de la versión de cgroup

stat -fc %T /sys/fs/cgroup

Los resultados son los siguientes:

Resultado Descripción
cgroup2fs Está usando cgroup v2
cgroup Está usando cgroup v1

Cambiar a el cgroup v2

La ruta de acceso más sencilla es elegir una distribución que admita cgroup v2 de fábrica.

Si necesita cambiar manualmente, agregue la siguiente línea a la configuración de GRUB:

systemd.unified_cgroup_hierarchy=1

A continuación, ejecute el siguiente comando para actualizar GRUB:

sudo update-grub

Para obtener más información, consulte los siguientes recursos:

Directrices para establecer límites de memoria

Al establecer límites de memoria para SQL Server en Linux, tenga en cuenta las instrucciones siguientes:

  • Use cgroup para limitar la memoria total disponible para el contenedor. Esta configuración establece el límite superior para todos los procesos dentro del contenedor.

  • El límite de memoria (ya sea establecido por memorylimitmb o la MSSQL_MEMORY_LIMIT_MB variable de entorno) controla la memoria total que SQL Server en Linux puede asignar en todos sus componentes, como el grupo de búferes, SQLPAL, Agente SQL Server, LibOS, PolyBase, Full-Text Search y cualquier otro proceso cargado en SQL Server en Linux.

  • La MSSQL_MEMORY_LIMIT_MB variable de entorno tiene prioridad sobre memorylimitmb la definida en mssql.conf.

  • memorylimitmb no puede superar la memoria física real del sistema host.

  • Establezca memorylimitmb un valor inferior a la memoria del sistema host y el límite de cgroup (si está presente), para asegurarse de que hay suficiente memoria física libre para el sistema operativo Linux. Si no establece memorylimitmbexplícitamente , SQL Server usa 80% del valor menor entre la memoria total del sistema y el límite de cgroup (si está presente).

  • La opción de configuración del servidor max_server_memory limita solo el tamaño del grupo de búferes de SQL Server y no rige el uso general de memoria para SQL Server en Linux. Establezca siempre este valor por debajo de memorylimitmb para asegurarse de que la memoria suficiente permanece para otros componentes, como SQLPAL, Agente SQL Server, LibOS, PolyBase, Full-Text Search y cualquier otro proceso cargado en SQL Server en Linux.

Contenido relacionado

  • Last updated on