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.

Configuração do sistema operacional Linux

Considere o uso das seguintes definições de configuração do SO Linux para experimentar o melhor desempenho para uma instalação do SQL Server.

Recomendação de configuração de armazenamento

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

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

Veja a seguir um exemplo de como criar um RAID de software no Linux nas Máquinas Virtuais do Azure. Um exemplo é fornecido abaixo, mas use o número apropriado de discos de dados para a taxa de transferência e a IOPS necessárias para os volumes com base nos requisitos de dados, do log de transações e da E/S do tempdb. Neste 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.

# To locate the devices (for example /dev/sdc) for RAID creation, use the lsblk command
# 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, é recomendável usar as configurações de RAID. A sunit (unidade de distribuição de sistema de arquivos) implantada e a largura da faixa devem corresponder à geometria de RAID. Aqui está um exemplo baseado em sistema de arquivos 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 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 do 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 de SQL Server e os arquivos de log de transações.

# Formatting the volume with XFS filesystem
mkfs.xfs /dev/md0 -f -L datavolume
mkfs.xfs /dev/md1 -f -L logvolume
mkfs.xfs /dev/md2 -f -L tempdb

Observação

É 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 de Linux, mas pode ser usada para fins de compatibilidade.

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

No exemplo, os parâmetros -n version=ci são usados para configurar o sistema de arquivos XFS de maneira a não diferenciar maiúsculas de minúsculas.

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 tópico, confira o artigo Considerações técnicas.

Abrir limitação de arquivo

O limite de arquivo aberto padrão geralmente é definido em 1024. Seu ambiente de produção pode exigir mais conexões do que o limite padrão. 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 unidade anexada ao sistema seja remontada automaticamente após uma reinicialização, ela deve ser adicionada ao arquivo /etc/fstab. Além disso, é altamente recomendável que o UUID (Identificador Universal Exclusivo) seja usado no /etc/fstab para fazer referência à unidade e não apenas ao nome do dispositivo (por exemplo, /dev/sdc1).

É altamente recomendável usar o atributo noatime com qualquer sistema de arquivos usado para armazenar arquivos de log e dados 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 acima, 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 a funcionalidade do 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 e o Red Hat Enterprise Linux 8.0 em diante dão suporte ao recurso de FUA no subsistema de E/S. Se você estiver usando o SQL Server 2017 (14.x) CU6 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 a configuração recomendada listada abaixo se as condições a seguir forem atendidas.

  • Como usar o SQL Server 2017 (14.x) CU6 e versões posteriores
  • Usando uma distribuição e uma versão do Linux que dão suporte ao recurso de FUA (Red Hat Enterprise Linux 8.0 ou superior ou o SUSE Linux Enterprise Server 12 SP5)
  • Hardware e/ou subsistema de armazenamento que dá suporte e está configurado para o recurso de FUA

Configuração recomendada:

  1. Habilitar 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), verificando 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

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 do SO Linux para ver o processo de definição dessas configurações. O uso do TuneD conforme descrito ajuda a definir várias configurações de CPUs e de kernel descritas abaixo.

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 dele abaixo 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
#
# A TuneD configuration for SQL Server on 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
#Note: If you are using Linux distributions with kernel versions greater than 4.18, please comment the following options as shown; otherwise, uncomment the following options if you are using distributions with kernel versions less than 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 de uma 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 ele está habilitado com o seguinte comando:

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 impacto 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 é 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 mencionadas abaixo estão disponíveis em adaptadores de rede 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 mencionadas abaixo são explicadas com exemplos, e os comandos usados são específicos para o tipo e o fornecedor do adaptador de rede.

  1. Como configurar o tamanho do buffer da porta de rede: No exemplo a seguir, o adaptador de rede é chamado de '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 os comandos de exemplo mostrados abaixo:

    #To check the pre-set maximums please run the command, example NIC name used here is:"eth0"
    ethtool -g eth0
    #command to set both the rx (receive) and tx (transmit) buffer size to 4 KB.
    ethtool -G eth0 rx 4096 tx 4096
    #command to check the value is properly configured is:
    ethtool -g eth0
    
  2. Habilitar quadros jumbo: antes de habilitar os quadros jumbo, verifique se todos os comutadores de rede, roteadores e qualquer outro item essencial no caminho do pacote de rede entre os clientes e o SQL Server dão suporte aos 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
    
  3. Por padrão, é recomendável configurar a porta para a união de IRQs RX/TX adaptável, o que significa que a entrega de interrupção será 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:

    #command to set the port for adaptive RX/TX IRQ coalescing
    ethtool -C eth0 adaptive-rx on
    ethtool -C eth0 adaptive-tx on
    #confirm the setting using the command:
    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:

    #commands to disable adaptive RX/TX IRQ coalescing
    ethtool -C eth0 adaptive-rx off
    ethtool -C eth0 adaptive-tx off
    #confirm the setting using the command:
    ethtool -c eth0
    #Let us set the rx-usecs parameter which specify how many microseconds after at least 1 packet is received before generating an interrupt, and the [irq] parameters are the corresponding delays in updating the #status when the interrupt is disabled. For Intel bases NICs below are good values to start with:
    ethtool -C eth0 rx-usecs 100 tx-frames-irq 512
    #confirm the setting using the command:
    ethtool -c eth0
    
  4. 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 Suporte da Microsoft, a desabilitação do RSS também aprimorou o desempenho. Teste essa configuração em ambientes de teste antes de aplicá-la em ambientes de produção. O comando de exemplo mostrado abaixo é para adaptadores de rede Intel.

    #command to get pre-set maximums
    ethtool -l eth0
    #note the pre-set "Combined" maximum value. let's consider for this example, it is 8.
    #command to combine the queues with the value reported in the pre-set "Combined" maximum value:
    ethtool -L eth0 combined 8
    #you can verify the setting using the command below
    ethtool -l eth0
    
  5. 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.

    Abaixo está um exemplo de infraestrutura de rede específica da Mellanox para ajudar a explicar a configuração. Para obter mais informações, confira Ferramentas de Ajuste de Desempenho para Adaptadores de Rede Mellanox. Os comandos serão alterados de acordo com o ambiente. Entre em contato com o fornecedor do adaptador de rede para obter mais diretrizes:

    #disable irqbalance or get a snapshot of the IRQ settings and force the daemon to exit
    systemctl disable irqbalance.service
    #or
    irqbalance --oneshot
    
    #download the Mellanox mlnx tools -- see https://support.mellanox.com/s/article/MLNX2-117-2523kn
    
    #be sure, common_irq_affinity.sh is executable. if not,
    #chmod +x common_irq_affinity.sh
    
    #display IRQ affinity for Mellanox NIC port; e.g eth0
    ./show_irq_affinity.sh eth0
    
    #optimize for best throughput performance with a Mellanox tool
    ./mlnx_tune -p HIGH_THROUGHPUT
    
    #set hardware affinity to the NUMA node hosting physically the NIC and its port
    ./set_irq_affinity_bynode.sh `\cat /sys/class/net/eth0/device/numa_node` eth0
    
    #verify IRQ affinity
    ./show_irq_affinity.sh eth0
    
    #add IRQ coalescing optimizations
    ethtool -C eth0 adaptive-rx off
    ethtool -C eth0 adaptive-tx off
    ethtool -C eth0  rx-usecs 750 tx-frames-irq 2048
    
    #verify the settings
    ethtool -c eth0
    
  6. 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 adicional de kernel/sistema operacional

  • Para obter o melhor desempenho de E/S de armazenamento, recomenda-se o uso do agendamento de multifila do Linux para dispositivos de bloco. Isso 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 estiver habilitada por padrão em suas distribuições do Linux. Na maioria dos outros casos, inicializar o kernel com scsi_mod.use_blk_mq=y a habilita, embora a documentação da distribuição do Linux em uso possa ter orientações adicionais. Isso é consistente com o kernel do Linux upstream.

  • Como a E/S de vários caminhos geralmente é usada para implantações do SQL Server, o destino de várias filas do DM (mapeador de dispositivos) também deve ser configurado para usar a infraestrutura blk-mq habilitando a opção de inicialização de 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. Consulte a documentação da distribuição Linux em uso para ver diretrizes adicionais sobre como configurá-la.

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

É recomendável executar 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

    É recomendável usar 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.

Próximas etapas