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

Se aplica a:SQL Server: 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

Normalmente, en entornos locales, el proveedor de almacenamiento admite la configuración de RAID de hardware adecuada con la división en varios discos para garantizar los valores adecuados de IOPS, rendimiento y redundancia. Pero esto puede diferir en otros proveedores de almacenamiento y en otras ofertas de almacenamiento con distintas arquitecturas.

En el caso de SQL Server en Linux implementado en Azure Virtual Machines, considere la posibilidad de usar RAID de software para asegurarse de que se consiguen los requisitos de rendimiento e 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.

El siguiente ejemplo muestra cómo crear RAID de software en Linux en Azure Virtual Machines. 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 siguiente ejemplo, se han conectado ocho discos de datos a la máquina virtual de Azure: cuatro para hospedar archivos de datos, dos para registros de transacciones y dos para la carga de trabajo de tempdb.

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, debe usar una configuración RAID. La unidad de franja del sistema de archivos implementada (sunit) y el ancho de franja deben coincidir con la geometría de RAID. Por ejemplo, se trata de un ejemplo basado 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 registro es una unidad RAID-10 de 6 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.

Recomendación de configuración del sistema de archivos

SQL Server es compatible con los sistemas de archivos ext4 y XFS para hospedar la base de datos, los registros de transacciones y archivos adicionales, como los de punto de comprobación para OLTP en memoria en SQL Server. Microsoft recomienda usar el sistema de archivos XFS para hospedar los archivos de datos y de registro de transacciones 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

Es posible configurar el sistema de archivos XFS para que no distinga mayúsculas de minúsculas al crear y dar formato al volumen XFS. No es la configuración que se usa habitualmente en el ecosistema de Linux, pero se puede usar por motivos de compatibilidad.

Por ejemplo, puede ejecutar el siguiente comando. -n version=ci se usa para configurar el sistema de archivos XFS para que no distinga mayúsculas de minú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, la asignación de bloques para el sistema de archivos subyacente debe ser de 2 MB. Para obtener más información sobre este tema, revise el artículo 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. Se recomienda establecer un límite flexible de 16.000 y un límite máximo de 32.727. Por ejemplo, en RHEL, edite el archivo /etc/security/limits.d/99-mssql-server.conf para que tenga los valores siguientes:

mssql hard nofile 32727
mssql soft nofile 16000

Deshabilitación de la última fecha y hora de acceso en los sistemas de archivos para los archivos de datos y de registro de SQL Server

Para asegurarse de que la unidad adjuntada al sistema se vuelve a montar de forma automática después de un reinicio, agréguela al archivo /etc/fstab. También debe usar el UUID (identificador único global) en /etc/fstab para hacer referencia a la unidad, en lugar de solo el nombre del dispositivo (por ejemplo, /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. A continuación se muestra un ejemplo de cómo habilitar la opción noatime para un volumen montado en la máquina virtual de 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

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

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 Optimizado configura de forma automática algunas opciones del kernel y la CPU (excepto para C-States). 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, el paquete tuned se puede instalar manualmente. Se puede usar para crear y configurar el perfil mssql, tal como se describe en la siguiente sección.

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 de Linux con versiones de kernel posteriores a la 4.18, comente las siguientes opciones tal como se muestra; de lo contrario, quite la marca de comentario de las siguientes opciones si usa distribuciones con versiones de kernel anteriores a la 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 Value 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

El uso de Optimizado, tal como se ha descrito antes, configura automáticamente el regulador de frecuencia de la CPU, ENERGY_PERF_BIAS y los valores correctos de min_perf_pct debido al perfil de rendimiento que se usa como base para el perfil mssql. El parámetro C-States se debe configurar manualmente 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 Value Más información
Disco readahead 4096 Consulte para el comando blockdev
la 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 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 de 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. Al establecer el valor 1 se indica una preferencia segura por mantener la memoria de proceso en tiempo de ejecución en la memoria física a costa de la caché del sistema de archivos. Como SQL Server usa el grupo de búferes como una caché de páginas de datos y prefiere escribir en el hardware físico omitiendo la caché del sistema de archivos para una recuperación confiable, la configuración de intercambio intenso puede ser beneficiosa para una instancia dedicada de SQL Server 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 totalmente justa (CFS) en el kernel de Linux, para mejorar el rendimiento de las llamadas de E/S de red y de almacenamiento con respecto a las operaciones de adelantamiento y reanudación de los subprocesos.

El uso del perfil Optimizado mssql configura las opciones vm.swappiness, vm.dirty_* y kernel.sched_*. La configuración del disco readahead mediante el comando blockdev se realiza por dispositivo y se debe realizar manualmente.

Configuración del equilibrio automático de NUMA del kernel con sistemas NUMA de varios nodos

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

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 deben tener esta opción activada de forma predeterminada. Se recomienda que, para obtener un rendimiento más coherente, deje habilitada esta opción de configuración. Pero, por ejemplo, si hay actividad de paginación de memoria alta en implementaciones de SQL Server con varias instancias, o la ejecución de SQL Server con otras aplicaciones que requieren mucha memoria del servidor, se recomienda probar el rendimiento de las aplicaciones después de ejecutar el comando siguiente:

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

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

vm.transparent_hugepages=madvise

Y active el perfil mssql 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

Al igual que existen recomendaciones de almacenamiento y de CPU, hay recomendaciones específicas de red que se enumeran a continuación 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 siguiente, 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 máximos establecidos previamente con el siguiente comando. 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, la habilitación de los marcos gigantes puede mejorar el rendimiento. Después de habilitar los marcos gigantes, conéctese a SQL Server y cambie el tamaño de los paquetes de red a 8060 con sp_configure como se muestra a continuación:

    # 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
    
    EXEC sp_configure 'network packet size', '8060';
    GO
    RECONFIGURE WITH OVERRIDE;
    GO
    
  3. De manera predeterminada, se recomienda establecer el puerto para la fusión de IRQ de RX/TX adaptable, lo que significa que la entrega de interrupción se ajusta para mejorar la latencia cuando la velocidad de los paquetes sea baja y mejorar el rendimiento cuando sea alta. Es posible que este valor no esté disponible en todas la infraestructuras de red, por lo que debe revisar la infraestructura de red existente y confirmar que es compatible. En el ejemplo siguiente, la NIC se denomina 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 obtener un comportamiento predecible en entornos de alto rendimiento, como los de pruebas comparativas, deshabilite la fusión de IRQ de RX/TX adaptable y, después, establezca específicamente la fusión 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 transcurren desde que se recibe al menos 1 paquete antes de 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. También se recomienda habilitar el escalado del lado de recepción (RSS) de manera predeterminada, para combinar los lados RX y TX de las colas de RSS. Ha habido escenarios concretos en los que, al trabajar con Soporte técnico de Microsoft, también se ha mejorado el rendimiento al deshabilitar RSS. 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. Trabajar con la afinidad de IRQ de puertos de NIC. Para lograr el rendimiento esperado mediante la modificación de la afinidad de IRQ, tenga en cuenta algunos parámetros importantes como el control por parte de Linux de la topología del servidor, la pila de controladores de NIC, la configuración predeterminada y el valor irqbalance. Las optimizaciones de la configuración de las afinidades de IRQ de puertos de NIC se realizan con el conocimiento de la topología del servidor, deshabilitando el valor irqbalance y con la configuración específica 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. Una vez que se hayan realizado los cambios anteriores, compruebe la velocidad de la NIC para asegurarse de que coincida con la esperada mediante el comando siguiente:

    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 de bloque, que 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. Consulte la documentación si está habilitada de forma predeterminada en las distribuciones de Linux. En la mayoría de los demás casos, el arranque del kernel con scsi_mod.use_blk_mq=y lo habilita, a pesar de que en la documentación de la distribución de Linux en uso se pueden incluir instrucciones adicionales. Esto es coherente con el kernel de Linux ascendente.

  • Como la E/S de múltiples rutas se suele usar para implementaciones de SQL Server, configure el destino de varias colas del asignador de dispositivos (DM) para usar la infraestructura de blk-mq habilitando la opción de arranque del kernel dm_mod.use_blk_mq=y. El valor predeterminado es n (deshabilitado). Esta opción, cuando los dispositivos SCSI subyacentes usan blk-mq, reduce la sobrecarga de bloqueo en el nivel de DM. 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 de la aplicación.

Procedimientos recomendados

Uso de PROCESS AFFINITY en el nodo o las CPU

Use ALTER SERVER CONFIGURATION para establecer PROCESS AFFINITY en todas las instancias de NUMANODE o las CPU que use para SQL Server (que suele ser para todos los NODE y las CPU) 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 disponible para el sistema operativo Linux, el proceso de SQL Server solo usa de forma predeterminada el 80 % de la RAM física. En algunos sistemas con gran cantidad de RAM física, el 20 % puede ser una cantidad considerable. 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. Consulte la documentación sobre la herramienta mssql-conf y la opción memory.memorylimitmb que controla la memoria visible para SQL Server (en unidades de MB).

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.