Práticas recomendadas de desempenho e diretrizes de configuração para SQL Server no Linux

Aplica-se a:SQL Server em 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 no Linux. Essas recomendações são específicas para rodar na plataforma Linux. Todas as recomendações normais do SQL Server, como design de índice, ainda se aplicam.

As diretrizes a seguir contêm recomendações para configurar o SQL Server e o sistema operacional Linux. Considere usar essas definições de configuração para obter o melhor desempenho para uma instalação do SQL Server.

• Recomendação de configuração de armazenamento
• Configurações de kernel e CPU de alto desempenho
• 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 na memória) deve ser capaz de gerenciar a carga de trabalho média e de pico normalmente.

Usar o subsistema de armazenamento com IOPS, throughput e redundância adequados.

Em ambientes locais, o fornecedor de armazenamento normalmente suporta a configuração RAID de hardware adequada com distribuição em faixas por múltiplos discos para garantir IOPS, rendimento e redundância adequados. No entanto, este suporte pode variar entre diferentes fornecedores e ofertas de armazenamento, com arquiteturas variadas.

Para SQL Server em Linux implementado em Máquinas Virtuais Azure, considere usar RAID por software para garantir os IOPS e os requisitos de throughput adequados. Ao configurar o SQL Server em máquinas virtuais do Azure com considerações de armazenamento semelhantes, consulte Configurar o armazenamento para o SQL Server em VMs do Azure.

O exemplo seguinte mostra como criar RAID de software em Linux numa Máquina Virtual Azure. Lembre-se de que você deve usar o número apropriado de discos de dados para a taxa de transferência necessária e IOPS para volumes com base nos dados, no log de transações e nos requisitos de E/S tempdb. No exemplo seguinte, oito discos de dados estavam ligados à VM; quatro para ficheiros de dados de alojamento, dois para registos 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 particionamento e configuração de disco

Para SQL Server, usa uma configuração RAID. A unidade de faixa do sistema de ficheiros implementada (sunit) e a largura da faixa correspondem à geometria do RAID. Por exemplo, o exemplo seguinte mostra uma configuração baseada em XFS para um volume logarítmico.

# 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

O array de logs é um RAID-10 de seis discos com uma faixa de 64 KB. Como você pode ver:

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

Configuração recomendada do sistema de ficheiros

O SQL Server suporta sistemas de ficheiros ext4 e XFS para alojar a base de dados, registos de transações e outros ficheiros, como ficheiros de checkpoint para OLTP em memória no SQL Server. Use o sistema de ficheiros XFS para alojar os ficheiros de dados e registos de transações do SQL Server.

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

Podes configurar o sistema de ficheiros XFS para ser insensível a maiúsculas minúsculas ao criar e formatar o volume XFS. Esta configuração não é frequentemente usada no ecossistema Linux, mas pode ser usada por razões de compatibilidade.

Por exemplo, você pode executar o seguinte comando. Use -n version=ci para configurar o sistema de ficheiros XFS para ser insensível a maiúsculas minúsculas.

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

Recomendação para o sistema de ficheiros de memória persistente

Para a configuração do sistema de ficheiros em dispositivos de Memória Persistente, defina a alocação de blocos para o sistema subjacente para 2 MB. Para mais informações, consulte Considerações Técnicas.

Limitação de arquivo aberto

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

mssql - nofile 1048576

Desative a data e hora do último acesso nos sistemas de ficheiros para dados e ficheiros de registo do SQL Server

Para garantir que os discos ligados ao sistema se remontam automaticamente após um reinício, adicione-os ao /etc/fstab ficheiro. Use o UUID (Identificador Universalmente Único) em /etc/fstab para se referir à unidade, em vez de apenas o 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. Consulte a documentação do Linux sobre como definir esse atributo. O exemplo seguinte mostra como ativar a noatime opção para um volume montado numa Máquina Virtual 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, UUID representa o dispositivo que você pode encontrar usando o comando blkid.

Capacidade do subsistema de E/S do SQL Server e da unidade de acesso forçado (FUA)

Certas versões de distribuições Linux suportadas fornecem suporte para a capacidade de subsistema de E/S FUA, que fornece durabilidade de dados. O SQL Server usa o recurso FUA para fornecer E/S altamente eficientes e confiáveis para cargas de trabalho do SQL Server. Para obter mais informações sobre o suporte de FUA pela distribuição Linux e o seu efeito no SQL Server, consulte SQL Server On Linux: Forced Unit Access (FUA) Internals.

O SUSE Linux Enterprise Server 12 SP5, o Red Hat Enterprise Linux 8.0 e o Ubuntu 18.04 introduziram suporte para o recurso FUA no subsistema de E/S. Se você estiver usando o SQL Server 2017 (14.x) 6 e versões posteriores, deverá usar a seguinte configuração para implementação de E/S eficiente e de alto desempenho com o FUA by SQL Server.

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

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

• Distribuição Linux e versão que suporta a capacidade FUA (começando com Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 ou Ubuntu 18.04)

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

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

  Observação

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

• Subsistema de armazenamento e/ou hardware compatível e configurado para capacidade 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 Linux) e certifique-se de que o sinalizador de rastreamento 3979 não esteja habilitado como um parâmetro de inicialização.

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

Suporte FUA para contêineres do SQL Server implantados no Kubernetes

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

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

   kubectl describe pv <pvc-name>
   

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

3. O nó de trabalho que hospeda os pods do SQL Server deve estar usando uma distribuição Linux e uma versão que suporte o 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ê pode usar as seguintes configurações de FUA recomendadas.

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 sistema operacional Linux relacionadas ao alto desempenho e à taxa de transferência para uma instalação do SQL Server. Consulte a documentação da sua distribuição Linux para obter o processo para definir essas configurações. Você pode usar TuneD conforme descrito, para configurar muitas CPUs e configurações de kernel, descritas na próxima seção.

Use TuneD para configurar as definições do kernel

Para os utilizadores do Red Hat Enterprise Linux (RHEL), o perfil de desempenho-rendimento do TuneD configura automaticamente algumas definições do kernel e da CPU (exceto para os C-States). Começando com o RHEL 8.0, um perfil TuneD chamado mssql foi desenvolvido em conjunto com a Red Hat e oferece ajustes mais finos relacionados ao desempenho do Linux para cargas de trabalho do SQL Server. Este perfil inclui o perfil de desempenho de taxa de transferência RHEL, e apresentamos suas definições neste artigo para sua revisão com outras distribuições Linux e versões RHEL sem esse perfil.

Para SUSE Linux Enterprise Server 12 SP5, Ubuntu 18.04 e Red Hat Enterprise Linux 7.x, pode instalar manualmente o tuned pacote. Utilize-o para criar e configurar o mssql perfil conforme descrito na secção seguinte.

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

O exemplo a seguir fornece uma configuração TuneD para SQL Server no 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ê usa distribuições Linux com versões do kernel maiores que 4.18, comente as seguintes opções conforme mostrado; caso contrário, descomente as seguintes opções se você usar distribuições com versões do kernel anteriores à 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 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

Verifique se o perfil está ativo, com o seguinte comando:

tuned-adm active

Ou:

tuned-adm list

Recomendação de configurações da CPU

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

Quando utilizas o TuneD conforme descrito, ele configura automaticamente o governador de frequência do CPU e as definições de ENERGY_PERF_BIAS e min_perf_pct. Utiliza o perfil de rendimento-desempenho como base para o mssql perfil. Deve configurar manualmente o parâmetro C-States de acordo com a documentação fornecida pelo Linux ou pelo distribuidor do seu sistema.

Recomendações de configurações de disco

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

Descrição

• vm.swappiness: Este parâmetro controla o peso relativo dado à troca da memória de processo em tempo de execução em comparação com a cache do sistema de ficheiros. O valor padrão deste parâmetro é 60, o que indica a troca de páginas de memória de processos em tempo de execução em comparação com a remoção de páginas de cache do sistema de ficheiros numa proporção de 60:140. Definir o valor para 1 indica uma forte preferência por manter a memória do processo em tempo de execução na memória física à custa da cache do sistema de ficheiros. Como o SQL Server utiliza o buffer pool como cache de página de dados, e prefere fortemente escrever diretamente para o hardware físico, contornando a cache do sistema de ficheiros para uma recuperação fiável, uma configuração agressiva de swappiness pode ser benéfica para um SQL Server dedicado e de alto desempenho.

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

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

• kernel.sched_*: Estes valores de parâmetros representam a recomendação atual para ajustar o algoritmo de Planeamento Completamente Justo (CFS) no kernel Linux. Melhoram o desempenho das chamadas de I/O de rede e armazenamento no que diz respeito à preempção entre processos e à reativação de threads.

Usar o mssql perfil TuneD configura as vm.swappiness, vm.dirty_*, e kernel.sched_* definições. Tem de configurar manualmente as definições do disco readahead usando o blockdev comando para cada dispositivo.

Definição do kernel para equilíbrio automático NUMA em sistemas NUMA multinódeos

Se instalar o SQL Server num sistema NUMA multinós, a seguinte definição do kernel kernel.numa_balancing está ativada por predefinição. Para permitir que o SQL Server opere com máxima eficiência num sistema NUMA, desative o autobalanceamento NUMA num sistema NUMA com múltiplos nós:

sysctl -w kernel.numa_balancing=0

Usar o perfil mssql TuneD configura a opção kernel.numa_balancing.

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

A configuração padrão do 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 vm.max_map_count para pelo menos 262144 para uma implantação do SQL Server e consulte a seção Configurações propostas do Linux usando um perfil mssql do TuneD para ajustes adicionais desses parâmetros do kernel. O valor máximo para vm.max_map_count é 2147483647.

sysctl -w vm.max_map_count=1600000

Usar o perfil mssql TuneD configura a opção vm.max_map_count.

Deixar Transparent Huge Pages (THP) ativado

A maioria das instalações Linux tem esta opção ativada por defeito. Para uma experiência de desempenho mais consistente, mantenha esta opção de configuração ativada. No entanto, se houver elevada atividade de paginação de memória em implementações SQL Server com múltiplas instâncias, ou em execução SQL Server com outras aplicações que consomem memória no servidor, teste o desempenho da sua aplicação após executar o seguinte comando:

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

Ou modifique o perfil mssql TuneD com a linha:

vm.transparent_hugepages=madvise

E certifique-se de que o mssql perfil está ativo após a modificação:

tuned-adm off
tuned-adm profile mssql

Usar o perfil mssql TuneD configura a opção transparent_hugepage.

Recomendações de configuração de rede

Além das recomendações de armazenamento e CPU, também tens recomendações específicas para a rede. As seguintes recomendações estão listadas para referência. Nem todas as configurações nos exemplos a seguir estão disponíveis em diferentes NICs. Contate e consulte fornecedores de NIC para obter orientação sobre cada uma destas opções. Teste e configure isso em ambientes de desenvolvimento antes de aplicá-los 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 de NIC e o fornecedor.

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

   Verifique os máximos predefinidos com o seguinte comando. Substitua eth0 pelo nome da NIC:

   ethtool -g eth0
   

   Defina o tamanho do buffer rx (receber) e tx (transmitir) para 4 KB:

   ethtool -G eth0 rx 4096 tx 4096
   

   Verifique se o valor está configurado corretamente:

   ethtool -g eth0
   

2. Ativar quadros jumbo. Antes de habilitar quadros jumbo, verifique se todos os switches de rede, roteadores e qualquer outro dispositivo essencial no caminho do pacote de rede entre os clientes e o SQL Server suportam quadros jumbo. Só então é que a ativação de frames jumbo pode melhorar o desempenho. Depois de os quadros jumbo estarem ativados, ligue-se ao SQL Server e altere o tamanho do pacote de rede para 8060 usando sp_configure, como mostrado no exemplo seguinte:

   # 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 defeito, configure a porta para coesão adaptativa de IRQ RX/TX, o que significa que a entrega de interrupções é ajustada para melhorar a latência quando a taxa de pacotes é baixa e otimizar o throughput quando a taxa de pacotes é elevada. Esta configuração pode não estar disponível em toda a sua infraestrutura de rede, por isso reveja a infraestrutura de rede existente e confirme que esta configuração é suportada. O exemplo é para a NIC chamada eth0, que é uma NIC baseada em Intel:

   1. Defina a porta para a coalescência adaptativa RX/TX IRQ:

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

   2. Confirme a configuração:

      ethtool -c eth0
      

   Observação

   Para comportamentos previsíveis em ambientes de alto desempenho, como ambientes para benchmarking, desative a coalescência adaptativa do IRQ RX/TX e depois defina especificamente a coalescência da interrupção RX/TX. Veja os comandos de exemplo para desativar a coalescência do IRQ RX/TX e, em seguida, defina especificamente os valores:

   Desative a coligação adaptativa RX/TX IRQ:

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

   Confirme a alteração:

   ethtool -c eth0
   

   Defina os parâmetros rx-usecs e irq. rx-usecs especifica quantos microssegundos após pelo menos um pacote ser recebido 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 NICs de bases Intel, você pode usar as seguintes configurações:

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

   Confirme a alteração:

   ethtool -c eth0
   

4. Ative a escalabilidade do lado de receção (RSS) e, por defeito, combine o lado RX e TX das filas RSS. Existem cenários específicos, ao trabalhar com o Suporte Microsoft, em que desativar 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.

   Obtenha os valores máximos predefinidos:

   ethtool -l eth0
   

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

   ethtool -L eth0 combined 8
   

   Verifique a configuração:

   ethtool -l eth0
   

5. Trabalhe com a afinidade de IRQ da interface NIC. Para alcançar o desempenho esperado ajustando a afinidade IRQ, considere alguns parâmetros importantes, como a gestão da topologia do servidor pelo Linux, stack do driver NIC, definições padrão e definições do irqbalance. As otimizações das definições de afinidades IRQ da porta da NIC são feitas com o conhecimento da topologia do servidor, desativando o irqbalance, e utilizando as definições específicas do fornecedor da NIC.

   O exemplo a seguir da infraestrutura de rede específica do Mellanox ajuda a explicar a configuração. Para obter mais informações e para baixar as ferramentas mlnx do Mellanox, consulte Ferramentas de ajuste de desempenho para adaptadores de rede Mellanox. Os comandos mudam com base no ambiente. Entre em contato com o fornecedor da NIC para obter mais orientações.

   Desative irqbalanceou obtenha um instantâneo das configurações de IRQ e force o daemon a sair:

   systemctl disable irqbalance.service
   

   Ou:

   irqbalance --oneshot
   

   Certifique-se de que common_irq_affinity.sh é executável:

   chmod +x common_irq_affinity.sh
   

   Exibir afinidade IRQ para a porta Mellanox NIC (por exemplo, eth0):

   ./show_irq_affinity.sh eth0
   

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

   ./mlnx_tune -p HIGH_THROUGHPUT
   

   Defina a afinidade de hardware para o nó NUMA que hospeda fisicamente a NIC e sua porta:

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

   Verifique a afinidade de IRQ:

   ./show_irq_affinity.sh eth0
   

   Adicionar otimizações de coalescência de 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 corresponde às suas expectativas usando o seguinte comando:

   ethtool eth0 | grep -i Speed
   

Configuração avançada do kernel e do SO

• Para obter o melhor desempenho de I/O de armazenamento, utilize o agendamento de múltiplas filas do Linux para dispositivos de bloco. Este método de agendamento permite que o desempenho da camada de blocos escale bem com discos de estado sólido (SSDs) rápidos e sistemas multicore. Consulta a documentação para ver se a tua distribuição Linux o ativa por defeito. Na maior parte dos outros casos, podes arrancar o kernel com scsi_mod.use_blk_mq=y para o ativar. A documentação da tua distribuição Linux pode ter mais orientações sobre esta definição. Esta configuração é consistente com o kernel Linux upstream.

• Como a multipath I/O é frequentemente usada em implementações SQL Server, configure o alvo multiqueue do device mapper (DM) para usar a blk-mq infraestrutura, ativando a dm_mod.use_blk_mq=y opção de arranque do kernel. O valor padrão é n (desabilitado). Esta 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 E/S multipath, consulte a documentação da sua distribuição Linux.

Configurar arquivo de permuta

Certifique-se de ter um arquivo de permuta configurado corretamente para evitar problemas de falta de memória. Consulte a documentação do Linux para saber como criar e dimensionar corretamente um arquivo de troca.

Máquinas virtuais e memória dinâmica

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

Configuração do SQL Server

Execute as seguintes tarefas de configuração após instalar o SQL Server no Linux para obter o melhor desempenho para a sua aplicação.

Melhores práticas

Use PROCESS AFFINITY para nodos e/ou CPUs

Use ALTER SERVER CONFIGURATION para definir PROCESS AFFINITY para todos os NUMANODEs e CPUs que está a usar para o SQL Server (que normalmente é para todos os NODES e CPUs) num sistema operativo Linux. A afinidade do processador ajuda a manter um comportamento eficiente de agendamento Linux e SQL. Usar a opção NUMANODE é o método mais simples. Use PROCESS AFFINITY mesmo se você tiver apenas um único nó NUMA no seu computador. Para obter mais informações sobre como definir PROCESS AFFINITY, consulte o artigo ALTER SERVER CONFIGURATION.

Configurar vários ficheiros de dados tempdb

Como uma instalação do SQL Server no Linux não oferece uma opção para configurar vários arquivos tempdb, recomendamos que você considere a criação de vários arquivos de dados tempdb após a instalação. Para obter mais informações, consulte as orientações 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 no Linux. Essas opções são baseadas nos requisitos da sua carga de trabalho e configuração do seu sistema operacional Linux.

Definir um limite de memória com mssql-conf

Para garantir que há memória física livre suficiente para o sistema operativo Linux, o processo SQL Server utiliza apenas 80% da RAM física por defeito. Para alguns sistemas com grandes quantidades de RAM física, 20% pode 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 sem uso. Nessa situação, convém configurar o limite de memória para um valor mais alto. Pode ajustar este valor com a ferramenta mssql-conf . Para mais informações, consulte a definição memory.memorylimitmb que controla a memória visível para o SQL Server (em unidades de MB).

Ao alterar essa configuração, tenha cuidado para não definir esse valor muito alto. Se você não deixar memória suficiente, você pode ter problemas com o sistema operacional Linux e outros aplicativos Linux.

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

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

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

Verifique a versão do cgroup

stat -fc %T /sys/fs/cgroup

Os resultados são os seguintes:

Mudar para cgroup v2

O caminho mais fácil é escolher uma distribuição que suporte cgroup v2 fora da caixa.

Se você precisar alternar manualmente, adicione a seguinte linha à sua 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:

• Guia de início rápido: implantar um contêiner Linux do SQL Server no Kubernetes usando gráficos Helm
• Documentação do Linux Kernel cgroup v2
• Grupo de Controlo v2

Diretrizes para definir limites de memória

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

• Use cgroup para limitar a memória total disponível para o contentor. Esta definição estabelece o limite superior para todos os processos dentro do contentor.

• O limite de memória (seja definido por memorylimitmb ou pela 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 buffer pool, SQLPAL, SQL Server Agent, LibOS, PolyBase, Full-Text Search e qualquer outro processo carregado no SQL Server no Linux.

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

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

• Defina memorylimitmb menos do que a memória do sistema anfitrião e o limite cgroup (se existir), para garantir que há memória física livre suficiente para o sistema operativo Linux. Se não definir memorylimitmbexplicitamente , o SQL Server usa 80% do valor menor entre a memória total do sistema e o limite cgroup (se existir).

• A opção de configuração max_server_memory servidor limita apenas o tamanho do buffer pool do SQL Server e não regula o uso total de memória do SQL Server no Linux. Defina sempre este valor abaixo de memorylimitmb para garantir que memória suficiente permaneça para outros componentes, como SQLPAL, SQL Server Agent, LibOS, PolyBase, Pesquisa de Texto Completo e qualquer outro processo carregado no SQL Server no Linux.

Conteúdo relacionado

• Passo a passo para os recursos de desempenho do SQL Server no Linux
• O que é o SQL Server no Linux?