Melhores práticas de desempenho e diretrizes de configuração para o SQL Server em Linux

Aplica-se a:SQL Server – Linux

Este artigo fornece práticas recomendadas e recomendações para maximizar o desempenho de aplicativos de banco de dados que se conectam ao SQL Server em Linux. Estas recomendações são específicas para a execução na plataforma Linux. Todas as recomendações normais para o SQL Server, tais como design de índice, ainda se aplicam.

As diretrizes a seguir contêm recomendações para configurar o SQL Server e o SO (sistema operacional) Linux. Considere o uso das seguintes definições de configuração para experimentar o melhor desempenho para uma instalação do SQL Server.

• Recomendação de configuração de armazenamento
• Configurações de kernel e CPU para alta performance
• Configuração do SQL Server

Recomendação de configuração de armazenamento

O subsistema de armazenamento que hospeda dados, logs de transações e outros arquivos associados (como arquivos de ponto de verificação para OLTP in-memory) deve ser capaz de gerenciar as cargas de trabalho média e de pico normalmente.

Use o subsistema de armazenamento com IOPS, taxa de transferência e redundância apropriados

Em ambientes instalados no local, o fornecedor de armazenamento normalmente dá suporte à configuração de RAID de hardware apropriada com distribuição por faixas em vários discos para garantir IOPS, taxa de transferência e redundância adequadas. No entanto, esse suporte pode ser diferente entre diferentes fornecedores de armazenamento e ofertas de armazenamento diferentes com arquiteturas variadas.

Para o SQL Server no Linux implantado em Máquinas Virtuais do Azure, considere o uso de RAID de software para garantir os requisitos apropriados de IOPS e taxa de transferência. Ao configurar o SQL Server nas máquinas virtuais do Azure tendo considerações de armazenamento semelhantes, consulte Configurar o armazenamento para o SQL Server nas VMs do Azure.

O exemplo a seguir mostra como criar RAID de software no Linux em uma Máquina Virtual do Azure. Lembre-se de usar o número apropriado de discos de dados para a taxa de transferência e as IOPS necessárias para os volumes com base nos requisitos de dados, do log de transações e da E/S do tempdb. No exemplo a seguir, oito discos de dados foram anexados à VM; quatro para hospedar arquivos de dados, dois para logs de transações e dois para tempdb carga de trabalho.

Para localizar os dispositivos (por exemplo /dev/sdc) para a criação de RAID, use o 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

Recomendações de configuração e particionamento de disco

Para o SQL Server, use uma configuração RAID. A unidade de distribuição do sistema de arquivos implantada (sunit) e a largura da faixa correspondem à geometria RAID. Por exemplo, o exemplo a seguir mostra uma configuração baseada em XFS para um volume de log.

# 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

A matriz de log é um RAID-10 de seis unidades com um stripe de 64 KB. Como você pode ver:

• Para sunit=16 blks, um tamanho de bloco 16 * 4096 = 64 KB, corresponde ao tamanho da faixa.
• Para swidth=48 blks, swidth / sunit = 3, que é o número de unidades de dados na matriz, excluindo as unidades de paridade.

Configuração recomendada do sistema de arquivos

O SQL Server dá suporte a sistemas de arquivos ext4 e XFS para hospedar o banco de dados, logs de transações e outros arquivos, como arquivos de ponto de verificação para OLTP na memória no SQL Server. Use o sistema de arquivos XFS para hospedar os dados do SQL Server e os arquivos de log de transações.

Formate o volume com o sistema de arquivos XFS:

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

Você pode configurar o sistema de arquivos XFS para não diferenciar maiúsculas de minúsculas ao criar e formatar o volume XFS. Essa configuração não é usada com frequência no ecossistema do Linux, mas pode ser usada por motivos de compatibilidade.

Por exemplo, você pode executar o seguinte código. Use -n version=ci para configurar o sistema de arquivos XFS para não diferenciar maiúsculas de minúsculas.

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

Recomendação do sistema de arquivos de PMEM

Para a configuração do sistema de arquivos em dispositivos de Memória Persistente, defina a alocação de blocos para o sistema de arquivos subjacente como 2 MB. Para obter mais informações, consulte considerações técnicas.

Abrir limitação de arquivo

Seu ambiente de produção pode exigir mais conexões do que o limite de arquivo aberto padrão de 1.024. Você pode definir limites suaves e rígidos para 1.048.576. Por exemplo, no RHEL, edite o arquivo /etc/security/limits.d/99-mssql-server.conf para ter os seguintes valores:

mssql - nofile 1048576

Observação

Essa configuração não é aplicável a serviços SQL Server iniciados pelo systemd. Para obter mais informações, consulte Como definir limites para serviços no RHEL e systemd.

Desabilitar data e hora acessadas pela última vez em sistemas de arquivos para arquivos de log e dados do SQL Server

Para garantir que as unidades anexadas ao sistema sejam remontadas automaticamente após uma reinicialização, adicione-as ao arquivo /etc/fstab. Use o UUID (Identificador Universal Exclusivo) em /etc/fstab para se referir à unidade, ao invés de apenas ao nome do dispositivo (como /dev/sdc1).

Use o atributo noatime com qualquer sistema de arquivos que armazene dados e arquivos de log do SQL Server. Confira a documentação do Linux sobre como definir esse atributo. O exemplo a seguir mostra como habilitar a opção noatime para um volume montado em uma Máquina Virtual do Azure.

A entrada do ponto de montagem em /etc/fstab:

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

No exemplo anterior, a UUID representa o dispositivo que você pode encontrar usando o comando blkid.

Recurso de subsistema de E/S de FUA (Acesso forçado à unidade) e SQL Server

Algumas versões de distribuições do Linux compatíveis fornecem suporte à funcionalidade de subsistema de E/S do FUA, que oferece durabilidade de dados. O SQL Server usa o recurso FUA para fornecer E/S altamente eficiente e confiável para as cargas de trabalho do SQL Server. Para saber mais sobre o suporte do FUA pela distribuição do Linux e o impacto dele no SQL Server, confira SQL Server em Linux: Elementos internos do FUA (Acesso forçado à unidade).

O SUSE Linux Enterprise Server 12 SP5, o Red Hat Enterprise Linux 8.0 e o Ubuntu 18.04 apresentaram o suporte ao recurso FUA no subsistema de E/S. Se você está usando o SQL Server 2017 (14.x) CU 6 e versões posteriores, use a configuração a seguir para obter uma implementação de E/S eficiente e de alto desempenho com o FUA pelo SQL Server.

Use esta configuração recomendada se as condições a seguir forem atendidas.

• SQL Server 2017 (14.x) CU 6 e versões posteriores

• Distribuição e versão do Linux que dão suporte ao recurso FUA (começando com o Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 ou Ubuntu 18.04)

• Sistema de arquivos XFS para armazenamento do SQL Server, no kernel 4.18 ou versões posteriores do Linux.

• sistema de arquivos ext4 para armazenamento do SQL Server, no kernel 5.6 ou versões posteriores do Linux.

  Observação

  Você deve usar o sistema de arquivos XFS para hospedar arquivos de log de transações e dados do SQL Server quando a versão do kernel do Linux for inferior a 5.6. A partir do kernel versão 5.6, você pode escolher entre XFS e ext4 com base em seus requisitos específicos.

• Hardware e/ou subsistema de armazenamento que dá suporte e está configurado para o recurso FUA

Configuração recomendada:

1. Habilite o sinalizador de rastreamento 3979 como um parâmetro de inicialização.

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

Para quase todas as outras configurações que não atendem às condições anteriores, a configuração recomendada é a seguinte:

1. Habilite o sinalizador de rastreamento 3982 como um parâmetro de inicialização (que é o padrão para o SQL Server no ecossistema do Linux) e verifique se o sinalizador de rastreamento 3979 não está habilitado como um parâmetro de inicialização.

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

Suporte ao FUA para contêineres de SQL Server implantados no Kubernetes

1. O SQL Server deve usar o armazenamento montado persistente e não overlayfs.

2. O armazenamento deve usar os sistemas de arquivos XFS ou ext4 e deve dar suporte a FUA (ext4 não dá suporte a FUA no kernel do Linux anterior à versão 5.6). Antes de habilitar essa configuração, você deve trabalhar com o fornecedor de armazenamento e distribuição do Linux para garantir que o sistema operacional e o subsistema de armazenamento ofereçam suporte a opções FUA. No Kubernetes, você pode consultar o tipo de sistema de arquivos usando o seguinte comando, em que <pvc-name> é o seu PersistentVolumeClaim:

   kubectl describe pv <pvc-name>
   

   Na saída, procure o fstype que está definido como XFS.

3. O nó de trabalho que hospeda os pods do SQL Server deve estar usando uma distribuição e versão do Linux que ofereça suporte ao recurso FUA (começando com o Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 ou Ubuntu 18.04).

Se as condições acima forem atendidas, você poderá usar as configurações do FUA recomendadas a seguir.

1. Habilite o sinalizador de rastreamento 3979 como um parâmetro de inicialização.

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

Configurações de kernel e CPU para alto desempenho

A seção a seguir descreve as configurações recomendadas do SO Linux relacionadas ao alto desempenho e à taxa de transferência para uma instalação do SQL Server. Confira a documentação de distribuição do Linux para ver o processo de definição dessas configurações. Você pode usar o TuneD conforme descrito, para definir muitas configurações de CPUs e kernel, descritas na próxima seção.

Usar o TuneD para definir as configurações de kernel

Para usuários do RHEL (Red Hat Enterprise Linux), o perfil de throughput-performance do TuneD configura automaticamente algumas configurações de kernel e CPU (exceto para C-States). Do RHEL 8.0 em diante, um perfil do TuneD chamado mssql foi codesenvolvido com a Red Hat e oferece ajustes mais refinados relacionados ao desempenho do Linux para as cargas de trabalho do SQL Server. Esse perfil inclui o perfil de desempenho de taxa de transferência do RHEL, e apresentamos as definições neste artigo para sua análise com outras distribuições do Linux e versões do RHEL sem esse perfil.

Para o SUSE Linux Enterprise Server 12 SP5, Ubuntu 18.04 e Red Hat Enterprise Linux 7.x, você pode instalar manualmente o tuned pacote. Use-o para criar e configurar o mssql perfil, conforme descrito na seção a seguir.

Configurações propostas do Linux com o uso de um perfil mssql do TuneD

O exemplo a seguir fornece uma configuração de TuneD para SQL Server em 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

Se você usar distribuições Linux com versões do kernel superiores a 4.18, comente as opções a seguir conforme mostrado; caso contrário, descomente as opções a seguir se você usar distribuições com versões do 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 esse perfil do TuneD, salve essas definições em um arquivo tuned.conf na pasta /usr/lib/tuned/mssql e habilite o perfil usando os seguintes comandos:

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

Use o seguinte comando para verificar se o perfil está ativo:

tuned-adm active

Ou:

tuned-adm list

Recomendação de configurações de CPU

A tabela a seguir fornece recomendações para as configurações de CPU:

Configuração	Valor	Mais informações
Administrador de frequência de CPU	desempenho	Confira o comando cpupower
ENERGY_PERF_BIAS	desempenho	Confira o comando x86_energy_perf_policy
percentual_minimo_de_performance	100	Confira a documentação sobre o Intel p-state
C-States	Somente C1	Confira a documentação do Linux ou do sistema sobre como garantir que os C-States sejam definidos apenas como C1

Quando você usa o TuneD conforme descrito, ele configura automaticamente o controlador de frequência da CPU, ENERGY_PERF_BIAS, e min_perf_pct as configurações. Ele usa o perfil de desempenho da taxa de transferência como base para o perfil mssql. Você deve configurar manualmente o parâmetro C-States de acordo com a documentação fornecida pelo Linux ou pelo distribuidor do sistema.

Recomendações de configurações de disco

A tabela a seguir fornece recomendações para as configurações de disco:

Configuração	Valor	Mais informações
Disco readahead	4096	Confira o comando blockdev
Configurações 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	Confira o comando sysctl

Descrição

• vm.swappiness: Esse parâmetro controla o peso relativo dado para a troca de memória de processos em tempo de execução em comparação com o cache do sistema de arquivos. O valor padrão para esse parâmetro é 60, o que indica a troca de páginas de memória do processo de runtime em comparação com a remoção de páginas de cache do sistema de arquivos em uma taxa de 60:140. Definir o valor como 1 indica uma forte preferência para manter a memória do processo de runtime na memória física às custas do cache do sistema de arquivos. Como o SQL Server usa o pool de buffers como um cache de página de dados e prefere gravar em hardware físico ignorando o cache do sistema de arquivos para recuperação confiável, uma configuração agressiva de troca pode ser benéfica para o SQL Server dedicado e de alto desempenho.

  Você pode encontrar informações adicionais na Documentação para /proc/sys/vm/ – #swappiness

• vm.dirty_*: os acessos de gravação de arquivo do SQL Server não são armazenados em cache, atendendo aos seus requisitos de integridade de dados. Esses parâmetros permitem um desempenho de gravação assíncrona eficiente e reduzem o efeito de E/S de armazenamento das gravações de cache do Linux, permitindo um cache grande o suficiente enquanto limita a liberação.

• kernel.sched_*: esses valores de parâmetro representam a recomendação atual para ajustar o algoritmo CFS (Agendamento Completamente Justo) no kernel do Linux. Eles aprimoram a taxa de transferência de chamadas de E/S de rede e armazenamento em relação à preempção entre processos e à retomada de threads.

Usar o perfil mssql do TuneD configura as configurações de vm.swappiness, vm.dirty_* e kernel.sched_*. Você deve definir manualmente a configuração de disco readahead usando o blockdev comando para cada dispositivo.

Definição do kernel para balanceamento automático de NUMA em sistemas NUMA de vários nós

Se você instalar o SQL Server em um sistema NUMA de vários nós, a seguinte kernel.numa_balancing configuração de kernel será habilitada por padrão. Para permitir que o SQL Server opere com eficiência máxima em um sistema NUMA, desabilite o balanceamento NUMA automático em um sistema NUMA de vários nós:

sysctl -w kernel.numa_balancing=0

O uso do perfil mssql do TuneD configura a opção kernel.numa_balancing.

Configurações de kernel para o espaço de endereço virtual

A configuração padrão de vm.max_map_count (que é 65536) pode não ser alta o suficiente para uma instalação do SQL Server. Por esse motivo, altere o valor de vm.max_map_count para, no mínimo, 262144 em uma implantação do SQL Server e veja a seção Configurações propostas do Linux com o uso de um perfil mssql do TuneD para obter ajustes adicionais para esses parâmetros de kernel. O valor máximo para vm.max_map_count é de 2147483647.

sysctl -w vm.max_map_count=1600000

O uso do perfil mssql do TuneD configura a opção vm.max_map_count.

Deixar THP (páginas enormes transparentes) habilitadas

A maioria das instalações do Linux tem essa opção ativada por padrão. Para obter a experiência de desempenho mais consistente, deixe essa opção de configuração habilitada. No entanto, se houver alta atividade de paginação de memória em implantações do SQL Server com várias instâncias ou execução do SQL Server com outros aplicativos que exigem memória no servidor, teste o desempenho do aplicativo depois de executar o seguinte comando:

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

Ou, então, modifique o perfil mssql do TuneD com a linha:

vm.transparent_hugepages=madvise

E verifique se o mssql perfil está ativo após a modificação:

tuned-adm off
tuned-adm profile mssql

O uso do perfil mssql do TuneD configura a opção transparent_hugepage.

Recomendações de configuração de rede

Junto com as recomendações de armazenamento e CPU, você também tem recomendações específicas de rede. As recomendações a seguir são listadas para referência. Nem todas as configurações nos exemplos a seguir estão disponíveis em NICs diferentes. Consulte os fornecedores de adaptador de rede para obter diretrizes para cada uma dessas opções. Teste e configure essas recomendações em ambientes de desenvolvimento antes de aplicá-las em ambientes de produção. As opções a seguir são explicadas com exemplos, e os comandos usados são específicos para o tipo e fornecedor de NIC.

1. Configurar o tamanho do buffer da porta de rede. No exemplo, a NIC é nomeada eth0, que é uma NIC baseada em Intel. Para adaptadores de rede baseados em Intel, o tamanho de buffer recomendado é de 4 KB (4096). Verifique os máximos predefinidos e configure-os usando o seguinte exemplo:

   Verifique os valores máximos predefinidos com o comando a seguir. Substitua eth0 pelo seu nome do adaptador de rede:

   ethtool -g eth0
   

   Defina o tamanho do buffer rx (recebimento) e tx (transmissão) como 4 KB:

   ethtool -G eth0 rx 4096 tx 4096
   

   Verifique se o valor está configurado corretamente:

   ethtool -g eth0
   

2. Habilite quadros jumbo. Antes de habilitar os quadros jumbo, verifique se todos os comutadores de rede, roteadores e qualquer outra coisa essencial no caminho do pacote de rede entre os clientes e o SQL Server dão suporte a quadros jumbo. Só então é possível habilitar quadros jumbo para melhorar o desempenho. Depois que os quadros jumbo estiverem habilitados, conecte-se ao SQL Server e altere o tamanho do pacote de rede para 8060 usando sp_configure, conforme mostrado no exemplo a seguir:

   # 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. Por padrão, defina a porta para a coalescagem adaptável RX/TX IRQ, o que significa que a entrega de interrupção é ajustada para melhorar a latência quando a taxa de pacotes é baixa e melhorar a taxa de transferência quando a taxa de pacotes é alta. Essa configuração pode não estar disponível em sua infraestrutura de rede, portanto, examine a infraestrutura de rede existente e confirme se essa configuração tem suporte. O exemplo é para a NIC nomeada eth0, que é uma NIC baseada em Intel:

   1. Definir a porta para a união adaptável RX/TX IRQ:

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

   2. Confirmar a configuração:

      ethtool -c eth0
      

   Observação

   Para comportamento previsível em ambientes de alto desempenho, como ambientes de benchmarking, desabilite a junção adaptável RX/TX IRQ e defina especificamente a junção de interrupção RX/TX. Confira os comandos de exemplo para desabilitar a união de IRQs RX/TX e depois definir especificamente os valores:

   Desabilitar a união adaptável RX/TX IRQ:

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

   Confirmar a alteração:

   ethtool -c eth0
   

   Defina os parâmetros rx-usecs e irq. rx-usecs especifica quantos microssegundos devem se passar após a recepção de pelo menos um pacote antes de gerar uma interrupção. O parâmetro irq especifica os atrasos correspondentes na atualização do status quando a interrupção é desabilitada. Para adaptadores de rede baseados em Intel, você pode usar as seguintes configurações:

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

   Confirmar a alteração:

   ethtool -c eth0
   

4. Habilite o Receive-Side Scaling (RSS) e, por padrão, combine o lado RX e TX das filas RSS. Há cenários específicos ao trabalhar com o Suporte da Microsoft, em que desabilitar o RSS também melhora o desempenho. Teste essa configuração em ambientes de teste antes de aplicá-la em ambientes de produção. O exemplo a seguir é para NICs Intel.

   Obter os valores máximos predefinidos:

   ethtool -l eth0
   

   Combine as filas com o valor relatado no valor máximo predefinido "Combinado". Neste exemplo, o valor está definido como 8:

   ethtool -L eth0 combined 8
   

   Verifique a configuração:

   ethtool -l eth0
   

5. Trabalhe com a afinidade IRQ da porta NIC. Para obter o desempenho esperado ajustando a afinidade IRQ, considere alguns parâmetros importantes, como o tratamento do Linux da topologia do servidor, a pilha do driver da placa de interface de rede (NIC), as configurações padrão e irqbalance configuração. As otimizações das configurações de afinidades IRQ da NIC são feitas com o conhecimento da topologia do servidor, desabilitando o irqbalance e usando as configurações específicas do fornecedor da NIC.

   O seguinte exemplo da infraestrutura de rede específica da Mellanox ajuda a explicar a configuração. Para obter mais informações e baixar as ferramentas mlnx de Mellanox, confira Ferramentas de Ajuste de Desempenho para Adaptadores de Rede Mellanox. Os comandos são alterados de acordo com o ambiente. Entre em contato com o fornecedor do adaptador de rede para obter mais diretrizes.

   Desabilite irqbalanceou obtenha uma instantâneo das configurações do IRQ e force o daemon a sair:

   systemctl disable irqbalance.service
   

   Ou:

   irqbalance --oneshot
   

   Garanta que common_irq_affinity.sh esteja executável:

   chmod +x common_irq_affinity.sh
   

   Exibir afinidade IRQ para a porta do adaptador de rede Mellanox (por exemplo, eth0):

   ./show_irq_affinity.sh eth0
   

   Otimizar para obter o melhor desempenho de taxa de transferência com uma ferramenta Mellanox:

   ./mlnx_tune -p HIGH_THROUGHPUT
   

   Definir a afinidade de hardware para o nó NUMA que hospeda fisicamente o adaptador de rede e sua porta:

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

   Verificar a afinidade do IRQ:

   ./show_irq_affinity.sh eth0
   

   Adicionar otimizações de união do IRQ

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

   Verifique as configurações:

   ethtool -c eth0
   

6. Depois de fazer as alterações anteriores, verifique a velocidade da NIC para garantir que ela corresponda às suas expectativas usando o seguinte comando:

   ethtool eth0 | grep -i Speed
   

Configuração avançada de kernel e sistema operacional

• Para obter o melhor desempenho de E/S de armazenamento, use o agendamento multiqueue do Linux para dispositivos de bloco. Esse método de agendamento permite que o desempenho da camada de blocos seja bem escalável com unidades de estado sólido (SSDs) rápidas e sistemas multicore. Verifique a documentação para ver se a distribuição do Linux a habilita por padrão. Em maioria dos outros casos, você pode inicializar o kernel com scsi_mod.use_blk_mq=y para habilitá-lo. A documentação da distribuição do Linux pode ter mais diretrizes sobre essa configuração. Essa configuração é consistente com o kernel upstream do Linux.

• Como a E/S de múltiplos caminhos é frequentemente usada para implantações do SQL Server, configure o alvo de fila múltipla do mapeador de dispositivos (DM) para usar a infraestrutura blk-mq, ativando a opção de inicialização do kernel dm_mod.use_blk_mq=y. O valor padrão é n (desabilitado). Essa configuração reduz a sobrecarga de bloqueio na camada DM quando os dispositivos SCSI subjacentes usam blk-mq. Para obter mais informações sobre como configurar a E/S de caminhos múltiplos, consulte a documentação da distribuição do Linux.

Configurar o arquivo de permuta

Verifique se você tem um swapfile configurado corretamente para evitar quaisquer problemas de memória insuficiente. Consulte a documentação do Linux para saber como criar e dimensionar corretamente um swapfile.

Máquinas virtuais e memória dinâmica

Se você está executando o SQL Server em Linux em uma máquina virtual, verifique se você selecionou as opções para corrigir a quantidade de memória reservada para a máquina virtual. Não use recursos como a Memória Dinâmica Hyper-V.

Configuração do SQL Server

Execute as seguintes tarefas de configuração depois de instalar o SQL Server no Linux para obter o melhor desempenho para seu aplicativo.

Práticas recomendadas

Usar PROCESS AFFINITY para o nó e/ou as CPUs

Use ALTER SERVER CONFIGURATION para definir PROCESS AFFINITY para todas as NUMANODEs e CPUs que você está usando no SQL Server (o que geralmente é para todos os NODEs e CPUs) em uma distribuição Linux. A afinidade do processador ajuda a manter eficiente o comportamento do agendamento do Linux e do SQL. O uso da opção NUMANODE é o método mais simples. Use PROCESS AFFINITY mesmo que você tenha apenas um único nó NUMA no computador. Para obter mais informações sobre como definir PROCESS AFFINITY, confira o artigo ALTER SERVER CONFIGURATION.

Configurar vários arquivos de dados do tempdb

Como uma instalação do SQL Server em Linux não oferece uma opção para configurar vários arquivos do tempdb, recomendamos que você considere a criação de vários arquivos de dados do tempdb após a instalação. Para obter mais informações, confira as diretrizes no artigo Recomendações para reduzir a contenção de alocação no banco de dados tempdb do SQL Server.

Configuração avançada

As recomendações a seguir são definições de configuração opcionais que você pode optar por executar após a instalação do SQL Server em Linux. Essas opções se baseiam nos requisitos de carga de trabalho e na configuração do SO Linux.

Definir um limite de memória com mssql-conf

Para garantir que haja memória física gratuita suficiente para o sistema operacional Linux, o processo do SQL Server usa apenas 80% da RAM física por padrão. Para alguns sistemas com grandes quantidades de RAM física, 20% podem ser um número significativo.

Por exemplo, em um sistema com 1 TB de RAM, a configuração padrão deixaria cerca de 200 GB de RAM não usada. Nessa situação, talvez você queira configurar o limite de memória para um valor mais alto. Você pode ajustar esse valor com a ferramenta mssql-conf . Para obter mais informações, consulte a configuração memory.memorylimitmb que controla a memória visível para o SQL Server (em unidades de MB).

Observação

Você também pode configurar um limite de memória usando a variável de MSSQL_MEMORY_LIMIT_MB ambiente. Esse método geralmente é usado ao implantar contêineres ou automatizar implantações baseadas em pacotes ou contêineres do SQL Server. A MSSQL_MEMORY_LIMIT_MB variável de ambiente tem precedência sobre a memory.memorylimitmb configuração.

Ao alterar essa configuração, tenha cuidado para não definir esse valor muito alto. Se você não tiver memória suficiente, poderá ter problemas com o SO Linux e outros aplicativos do Linux.

Configurar limites de memória com o cgroup (grupo de controle) v2

A partir do SQL Server 2025 (17.x) e do SQL Server 2022 (16.x) 20, o SQL Server detecta e respeita as restrições do grupo de controle (cgroup) v2, melhorando a estabilidade de desempenho e o isolamento de recursos nos ambientes docker, Kubernetes e OpenShift. Os grupos de controle habilitam o controle refinado no kernel do Linux sobre recursos do sistema, como CPU e memória.

Com o suporte ao cgroup v2, o SQL Server reduz erros de memória (OOM) observados anteriormente em implantações em contêineres, especialmente em clusters do Kubernetes (por exemplo, AKS v1.25+), em que os limites de memória definidos nas especificações do contêiner não eram impostos.

Verificar a versão do cgroup

stat -fc %T /sys/fs/cgroup

Os resultados são os seguintes:

Resultado	Descrição
cgroup2fs	Você está usando o cgroup v2
cgroup	Você está usando o cgroup v1

Alternar para cgroup v2

O caminho mais fácil é escolher uma distribuição que suporte o cgroup v2 pronto para uso.

Se você precisar alternar manualmente, adicione a seguinte linha à configuração do GRUB:

systemd.unified_cgroup_hierarchy=1

Em seguida, execute o seguinte comando para atualizar o GRUB:

sudo update-grub

Para obter mais informações, consulte os seguintes recursos:

• Início Rápido: Implantar um contêiner do SQL Server Linux no Kubernetes usando gráficos do Helm
• Documentação do cgroup do Kernel do Linux v2
• Grupo de Controle v2

Diretrizes para definir limites de memória

Ao definir limites de memória para o SQL Server no Linux, considere as seguintes diretrizes:

• Use cgroup para limitar a memória geral disponível para o contêiner. Essa configuração estabelece o limite superior para todos os processos dentro do contêiner.

• O limite de memória (definido por memorylimitmb ou a MSSQL_MEMORY_LIMIT_MB variável de ambiente) controla a memória total que o SQL Server no Linux pode alocar em todos os seus componentes, como o pool de buffers, SQLPAL, SQL Server Agent, LibOS, PolyBase, Full-Text Search e qualquer outro processo carregado no SQL Server no Linux.

• A MSSQL_MEMORY_LIMIT_MB variável de ambiente tem precedência sobre memorylimitmb definida em mssql.conf.

• memorylimitmb não pode exceder a memória física real do sistema host.

• Defina memorylimitmb menor que a memória do sistema host e o limite do cgroup (se presente), para garantir que haja memória física livre suficiente para o sistema operacional Linux. Se você não definir memorylimitmbexplicitamente, o SQL Server usará 80% do valor menor entre a memória total do sistema e o limite de cgroup (se presente).

• A opção de configuração do servidor max_server_memory limita apenas o tamanho do pool de buffers do SQL Server e não controla o uso geral de memória para o SQL Server no Linux. Sempre defina esse valor menor do que memorylimitmb para garantir que a memória suficiente permaneça para outros componentes, como SQLPAL, SQL Server Agent, LibOS, PolyBase, Full-Text Search e qualquer outro processo carregado no SQL Server no Linux.

Conteúdo relacionado

• Passo a passo dos recursos de performance do SQL Server no Linux
• O que é o SQL Server no Linux?