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

Artigo
07/13/2023

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

Normalmente, em ambientes locais, o fornecedor de armazenamento dá suporte à configuração de RAID de hardware apropriada com distribuição para vários discos para garantir IOPS, taxa de transferência e redundância apropriadas. No entanto, isso pode variar de acordo com diferentes fornecedores de armazenamento e diferentes ofertas de armazenamento com arquiteturas variadas.

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

O exemplo a seguir mostra como criar um RAID de software no Linux em Máquinas Virtuais 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 seguinte exemplo, oito discos de dados foram anexados à Máquina Virtual do Azure: quatro para hospedar arquivos de dados, dois para logs de transações e dois para a carga de trabalho do tempdb.

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

No caso do SQL Server, você deve usar uma configuração de RAID. A unidade de distribuição de sistema de arquivos sunit implantada e a largura da faixa devem corresponder à geometria de RAID. Este é um exemplo baseado em XFS relacionado a 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 uma faixa 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.

recomendação de configuração d sistema de arquivos

O SQL Server dá suporte a sistemas de arquivos ext4 e XFS para hospedar o banco de dados, os logs de transações e arquivos adicionais, como arquivos de ponto de verificação para OLTP in-memory no SQL Server. A Microsoft recomenda usar 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

É possível configurar o sistema de arquivos XFS para não diferenciar maiúsculas de minúsculas ao criar e formatar o volume XFS. Essa não é a configuração frequentemente usada no ecossistema Linux, mas pode ser usada para fins de compatibilidade.

Por exemplo, você pode executar o seguinte código. -n version=ci é usado 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, a alocação de bloco para o sistema de arquivos subjacente deve ser de 2 MB. Para saber mais sobre este artigo, confira 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 1024. Recomendamos que você defina um limite flexível de 16000 e um limite rígido de 32727. Por exemplo, no RHEL, edite o arquivo /etc/security/limits.d/99-mssql-server.conf para ter os seguintes valores:

mssql hard nofile 32727
mssql soft nofile 16000

Desabilitar data/hora do último acesso em sistemas de arquivos para arquivos de log e dados do SQL Server

Para garantir que a(s) unidade(s) conectada(s) ao sistema seja remontada automaticamente após uma reinicialização, adicione-as ao arquivo /etc/fstab. Você também deve usar o UUID (Identificador Universal Exclusivo) 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. Confira a documentação do Linux sobre como definir esse atributo. Veja abaixo um exemplo de como habilitar a opção noatime para um volume montado na 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 de SQL Server
Hardware e/ou subsistema de armazenamento que dá suporte e está configurado para o recurso FUA

Configuração recomendada:

Habilitar o Sinalizador de Rastreamento 3979 como um parâmetro de inicialização.
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:

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 verifique se o Sinalizador de Rastreamento 3979 não está habilitado como parâmetro de inicialização.
Use mssql-conf para configurar control.writethrough = 1 e control.alternatewritethrough = 1.

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

O SQL Server deve usar o armazenamento montado persistente e não overlayfs.
O armazenamento deve usar o sistema de arquivos XFS e deve dar suporte ao FUA. 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.
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.

Habilitar o Sinalizador de Rastreamento 3979 como um parâmetro de inicialização.
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 os usuários do RHEL (Red Hat Enterprise Linux), o perfil de desempenho de taxa de transferência do TuneD define algumas configurações de kernel e de CPU automaticamente (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, o Ubuntu 18.04 e o Red Hat Enterprise Linux 7.x, o pacote tuned pode ser instalado manualmente. Ele pode ser usado para criar e configurar o perfil mssql conforme descrito abaixo.

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 estiver usando distribuições Linux com versões de kernel superiores a 4.18, comente as seguintes opções conforme mostrado; caso contrário, remova o comentário das opções a seguir se estiver usando distribuições com versões de 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
min_perf_pct	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

O uso do TuneD conforme descrito anteriormente define automaticamente as configurações do administrador de frequência da CPU, ENERGY_PERF_BIAS, e de min_perf_pct adequadamente, devido ao perfil de desempenho de taxa de transferência ser usado como base para o perfil mssql. O parâmetro C-States deve ser configurado manualmente 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 do 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 fornecido para permuta da memória do processo de runtime em comparação com o cache do sistema de arquivos. O valor padrão para esse parâmetro é 60, que indica a permuta 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 na proporção de 60:140. Um valor definido como 1 indica uma preferência forte pela manutenção da memória do processo de runtime na memória física, em detrimento do cache do sistema de arquivos. Como o SQL Server usa o pool de buffers como um cache de página de dados e dá grande preferência para gravação em um hardware físico ignorando o cache do sistema de arquivos para uma recuperação confiável, a configuração de permuta agressiva pode ser benéfica para 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 de CFS (Completely Fair Scheduling) no kernel do Linux para melhorar a taxa de transferência de chamadas de E/S de rede e armazenamento com relação à preempção e à retomada de threads entre processos.

O uso do perfil mssql do TuneD define as configurações de vm.swappiness, vm.dirty_* e kernel.sched_*. A configuração readahead do disco usando o comando blockdev é feita por dispositivo e deve ser executada manualmente.

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

Se você instalar o SQL Server em um sistema NUMA de vários nós, a configuração de kernel kernel.numa_balancing a seguir estará habilitada por padrão. Para permitir que o SQL Server opere com eficiência máxima em um sistema NUMA, desabilite o balanceamento automático do NUMA 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 deve ter essa opção ativada por padrão. Para a experiência de desempenho mais consistente, recomendamos deixar essa opção de configuração habilitada. No entanto, se houver atividade de paginação de alta memória em implantações do SQL Server com várias instâncias, por exemplo, ou de execução do SQL Server com outros aplicativos que demandam memória no servidor, sugerimos que você teste o desempenho dos aplicativos após executar o comando a seguir:

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 torne o perfil mssql 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

Assim como há recomendações de CPU e de armazenamento, há também recomendações específicas de rede, listadas abaixo 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.

Configurar o tamanho do buffer da porta de rede. No exemplo a seguir, o adaptador de rede é chamado eth0, que é um adaptador de rede baseado 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 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
```
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. Somente então a habilitação dos quadros jumbo pode aprimorar 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 abaixo:
```
# 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
```
Por padrão, é recomendável configurar a porta para a união de IRQ RX/TX adaptável, o que significa que a entrega de interrupção é ajustada para aprimorar a latência quando a taxa de pacotes for baixa e aprimorar a taxa de transferência quando a taxa de pacotes for alta. Essa configuração pode não estar disponível em todas as diferentes infraestruturas de rede, ou seja, analise a infraestrutura de rede existente e confirme se há suporte para isso. O seguinte exemplo é para o adaptador de rede chamado eth0, que é um adaptador de rede baseado 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 um comportamento previsível para ambientes de alto desempenho, como ambientes para benchmark, desabilite a união de IRQs RX/TX adaptável e defina especificamente a uniã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 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 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
```
Também recomendamos que o RSS (Receive-Side Scaling) esteja habilitado e, por padrão, combinando o lado RX e TX das filas de RSS. Há cenários específicos em que, ao trabalhar com o Suporte da Microsoft, desabilitar o RSS também melhorou 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
```
Como trabalhar com a afinidade de IRQ da porta do adaptador de rede. Para obter o desempenho esperado ajustando a afinidade de IRQ, considere alguns parâmetros importantes, como a manipulação da topologia do servidor pelo Linux, a pilha do driver NIC, as configurações padrão e a configuração de irqbalance. As otimizações das configurações de afinidades de IRQ da porta do adaptador de rede são feitas com o conhecimento da topologia do servidor, a desabilitação do irqbalance e o uso das configurações específicas do fornecedor do adaptador de rede.

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
```
Depois que as alterações acima forem feitas, use o seguinte comando para verificar a velocidade do adaptador de rede a fim de garantir que ela corresponda à expectativa:
```
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 de múltiplas filas do Linux para dispositivos de bloco, o que permite que o desempenho da camada de bloco seja bem dimensionado com SSDs (unidades de estado sólido) rápidas e sistemas de vários núcleos. Confira na documentação se ela está habilitada por padrão em suas distribuições do Linux. Nos outros casos, em sua maioria, inicializar o kernel com scsi_mod.use_blk_mq=y habilita essa opção, embora a documentação da distribuição Linux em uso possa ter mais orientações sobre isso. Essa definição é consistente com o kernel do Linux upstream.
Como a E/S de caminhos múltiplos costuma ser usada para implantações do SQL Server, configure o destino de várias filas do DM (mapeador de dispositivos) para usar a infraestrutura blk-mq, habilitando a opção de inicialização do kernel dm_mod.use_blk_mq=y. O valor padrão é n (desabilitado). Essa configuração, quando dispositivos SCSI subjacentes estão usando blk-mq, reduz a sobrecarga de bloqueio na camada de DM. 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 tarefas de configuração a seguir depois de instalar o SQL Server em Linux para obter o melhor desempenho para o aplicativo.

Práticas recomendadas

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

Use ALTER SERVER CONFIGURATION para definir PROCESS AFFINITY para todos os NUMANODEs e/ou todas as CPUs que você está usando para o SQL Server (que normalmente se destina a todos os nós e todas as CPUs) em um sistema operacional 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 livre suficiente para o SO Linux, o processo de SQL Server usa apenas 80% da RAM física por padrão. Para alguns sistemas que têm grande quantidade 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 não usada. Nessa situação, talvez você queira configurar o limite de memória para um valor mais alto. Consulte a documentação sobre a ferramenta mssql-conf e a configuraçã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 tiver memória suficiente, poderá ter problemas com o SO Linux e outros aplicativos do Linux.

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

Recomendação de configuração de armazenamento

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

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

recomendação de configuração d sistema de arquivos

Recomendação do sistema de arquivos de PMEM

Abrir limitação de arquivo

Desabilitar data/hora do último acesso em sistemas de arquivos para arquivos de log e dados do SQL Server

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

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

Configurações de kernel e CPU para alto desempenho

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

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

Recomendação de configurações de CPU

Recomendações de configurações de disco

Descrição

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

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

Deixar THP (páginas enormes transparentes) habilitadas

Recomendações de configuração de rede

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

Configurar o arquivo de permuta

Máquinas virtuais e memória dinâmica

Configuração do SQL Server

Práticas recomendadas

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

Configurar vários arquivos de dados do `tempdb`

Configuração avançada

Definir um limite de memória com mssql-conf

Comentários

Comentários

Recursos adicionais

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

Recomendação de configuração de armazenamento

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

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

recomendação de configuração d sistema de arquivos

Recomendação do sistema de arquivos de PMEM

Abrir limitação de arquivo

Desabilitar data/hora do último acesso em sistemas de arquivos para arquivos de log e dados do SQL Server

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

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

Configurações de kernel e CPU para alto desempenho

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

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

Recomendação de configurações de CPU

Recomendações de configurações de disco

Descrição

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

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

Deixar THP (páginas enormes transparentes) habilitadas

Recomendações de configuração de rede

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

Configurar o arquivo de permuta

Máquinas virtuais e memória dinâmica

Configuração do SQL Server

Práticas recomendadas

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

Configurar vários arquivos de dados do tempdb

Configuração avançada

Definir um limite de memória com mssql-conf

Conteúdo relacionado

Comentários

Comentários

Recursos adicionais

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

Configurar vários arquivos de dados do `tempdb`