Melhores práticas de desempenho: Armazenamento, kernel, CPU e rede para SQL Server em Linux

Aplica-se a:SQL Server em Linux

Este artigo aborda recomendações de configuração do sistema operativo e hardware para maximizar o desempenho do SQL Server em Linux, incluindo armazenamento, kernel, CPU e definições de rede.

• 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 aloja dados, registos de transações e outros ficheiros associados (como ficheiros de checkpoint para OLTP em memória) deve gerir tanto as cargas médias como as de pico de forma eficiente.

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 do Azure, considere usar RAID por software para garantir IOPS e throughput adequados. Para considerações de armazenamento ao configurar o SQL Server em máquinas virtuais Azure, veja Configurar armazenamento para SQL Server em VMs Azure.

O exemplo seguinte mostra como criar RAID de software em Linux numa Máquina Virtual Azure. Utilize o número apropriado de discos de dados para o throughput exigido e IOPS para volumes com base nos requisitos de dados, registo de transações e tempdb E/S. No exemplo seguinte, oito discos de dados estão ligados à VM: quatro para ficheiros de dados do alojamento, dois para registos de transações e dois para tempdb carga de trabalho.

Para localizar os dispositivos (por exemplo, /dev/sdc) para criação de RAID, use o lsblk comando.

# 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 vês:

• 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 dados do SQL Server e ficheiros de registo de transações.

Formate o volume usando o sistema de ficheiros 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 não ser sensível a maiúsculas minúsculas quando crias e formatas o volume XFS. Esta configuração não é frequentemente usada no ecossistema Linux, mas pode usá-la por razões de compatibilidade.

Por exemplo, execute 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

O seu ambiente de produção pode exigir mais ligações do que o limite padrão de ficheiros abertos ( 1024 1.024). Podes definir limites suaves e rígidos para 1048576 (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 o sistema remonta automaticamente os discos 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 pode encontrar usando o blkid comando.

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

Algumas distribuições Linux suportadas implementam o Forced Unit Access (FUA) ao nível do subsistema de I/O para garantir a durabilidade dos dados. O SQL Server aproveita esta capacidade para fornecer desempenho eficiente e fiável de I/O para cargas de trabalho Linux. Para mais informações sobre o suporte a FUA em distribuições Linux e o seu efeito no SQL Server, consulte SQL Server em Linux: Forced Unit Access (FUA) Internals.

O suporte para FUA no subsistema de I/O foi introduzido no SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 e Ubuntu 18.04. No SQL Server 2017 (14.x) CU 6 e versões posteriores, use a seguinte configuração para permitir E/S de alto desempenho e eficiência com FUA no SQL Server.

Use esta configuração recomendada se forem cumpridas as seguintes condições:

• SQL Server 2017 (14.x) Atualização Cumulativa 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)

  Note

  A partir do SQL Server 2025 (17.x), o SUSE Linux Enterprise Server (SLES) não é suportado.

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

  Note

  Use o sistema de ficheiros XFS para alojar dados do SQL Server e ficheiros de registo de transações quando a versão do kernel Linux for inferior a 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 hardware que suporta e está 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 cumpram as condições anteriores, use a seguinte configuração recomendada:

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 ficheiros XFS ou ext4 e deve suportar FUA (o ext4 não suporta FUA no kernel Linux anterior à versão 5.6). Antes de ativar esta definição, trabalhe com o seu fornecedor de distribuição e armazenamento Linux para garantir que o sistema operativo e o subsistema de armazenamento suportam 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ó trabalhador que aloja os pods do SQL Server deve usar uma distribuição e versão Linux que suporte capacidade FUA (começando pelo Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 ou Ubuntu 18.04).

Se as condições anteriores forem cumpridas, utilize as seguintes definições recomendadas de FUA:

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). A partir do RHEL 8.0, pode usar um perfil TuneD chamado mssql que oferece ajustes mais precisos relacionados com desempenho Linux para cargas de trabalho do SQL Server. Este perfil baseia-se no perfil de rendimento-desempenho do RHEL. Como o mssql perfil expõe todas as suas definições, pode analisá-las e adaptá-las para outras distribuições Linux ou versões RHEL que não incluam este 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 usar distribuições Linux com versões do kernel superiores a 4.18, comente as seguintes opções mostradas. Caso contrário, descomenta as seguintes opções se usares 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 usando 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:

Description

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

  Pode encontrar informações adicionais em Documentação sobre /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.

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

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 definição padrão de vm.max_map_count é 65536 (65.536), o que pode não ser suficientemente alto para uma instalação do SQL Server. Por esta razão, altere o vm.max_map_count valor para pelo menos 262144 (262,144) para uma implementação do SQL Server. Para obter mais ajustes destes parâmetros do kernel, consulte a secção Definições propostas do Linux com um perfil TuneD mssql. O valor máximo para vm.max_map_count é 2147483647 (2.147.483.647).

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

Juntamente com as recomendações de armazenamento e CPU, considere as seguintes recomendações específicas de rede. Diferentes NIC oferecem diferentes definições. Consulte os fornecedores de NIC para orientação sobre cada uma destas opções. Teste e configure estas definições em ambientes de desenvolvimento antes de as aplicar 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 ativar os jumbo frames, ligue-se ao SQL Server e altere o tamanho do pacote de rede para 8060 usando sp_configure, como mostrado no seguinte exemplo:

   # 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. Configurar a coalescência adaptativa de IRQ. 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:

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

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

   Confirme a configuração:

   ethtool -c eth0
   

   Note

   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 placas de rede baseadas em Intel, pode usar as seguintes definições:

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

   Confirme a alteração:

   ethtool -c eth0
   

4. Ativar a escalabilidade do lado da receção (RSS) e, por predefinição, combinar os lados RX e TX das filas de 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. Configurar a afinidade IRQ da porta da 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. Pode otimizar as definições de afinidades IRQ da porta da NIC usando o seu conhecimento da topologia do servidor, desativando o irqbalance, e usando 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 afinidade de hardware para o nó NUMA que aloja fisicamente a NIC e a 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 as 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. Verifica a velocidade da placa de rede. 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 o I/O multipath é frequentemente utilizado em implementações de SQL Server, configure o destino multiqueue do device mapper (DM) para utilizar a infraestrutura blk-mq, ativando a opção de arranque do kernel dm_mod.use_blk_mq=y. 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 mais informações sobre como configurar E/S multicaminho, 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. Se planeias correr containers, ativa o swap space ao nível do host.

Máquinas virtuais e memória dinâmica

Se estiveres a correr SQL Server em Linux numa máquina virtual, certifica-te de que escolhes opções que resolvam 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

As seguintes práticas aplicam-se a todas as implementações de SQL Server em Linux.

Utilizar PROCESS AFFINITY para o nó e os CPUs

Utilize ALTER SERVER CONFIGURATION para definir PROCESS AFFINITY para todos os NUMANODEs e CPUs que estiver a utilizar com o SQL Server (o que normalmente se aplica a todos os NODEs e CPUs) num sistema operativo Linux. A afinidade do processador ajuda a manter um agendamento eficiente no Linux e no SQL. Usar a opção NUMANODE é o método mais simples. Usa PROCESS AFFINITY mesmo que tenhas apenas um nó NUMA no teu computador. Para mais informações sobre como definir PROCESS AFFINITY, consulte o ALTER SERVER CONFIGURATION artigo.

Configurar vários ficheiros de dados tempdb

Como uma instalação SQL Server em Linux não oferece opção para configurar vários tempdb ficheiros, considere criar vários tempdb ficheiros de dados após a instalação. Para obter mais informações, consulte Recomendações para reduzir a contenção de alocação na base de dados tempdb do Microsoft SQL Server.

Configuração avançada

Para opções de configuração de memória, incluindo mssql-conf limites de memória, definições cgroup, exemplos de memória de contentores Docker e considerações sobre swap space, veja Melhores práticas de desempenho: SQL Server memory on Linux.

Conteúdo relacionado

• Melhores práticas de desempenho: memória do SQL Server em Linux
• Vistas e funções de gestão dinâmica relacionadas com Linux (Transact-SQL)
• Passo a passo para os recursos de desempenho do SQL Server no Linux
• O que é o SQL Server no Linux?