perfis otimizados para a otimização da carga de trabalho do servidor

As configurações padrão do Linux são ajustadas para compatibilidade, não para desempenho. O daemon tuned fornece perfis predefinidos que ajustam controladores de CPU, agendadores de E/S, parâmetros do kernel e buffers de rede para corresponder a uma carga de trabalho específica. Esta publicação aborda como os perfis funcionam, qual escolher para funções comuns de servidor e como criar e implementar perfis personalizados numa frota.

Como funcionam os perfis ajustados

Um perfil é um diretório no /usr/lib/tuned/profiles/ (sistema) ou /etc/tuned/profiles/ (custom) que contém um tuned.conf ficheiro. O ficheiro de configuração agrupa os parâmetros por plugin: [cpu], [disk], [sysctl], [vm], [bootloader], e assim por diante. Ative um perfil e o daemon do tuned aplica todos os parâmetros de uma só vez, em vez de executar dezenas de sysctl e sysfs comandos manualmente.

Os perfis podem herdar uns dos outros com a include . O throughput-performance perfil, por exemplo, pode servir de base para um perfil de base de dados personalizado que substitua apenas vm.swappiness a configuração de Páginas Gigantes Transparentes.

O tuned funciona em dois modos. O ajuste estático aplica o perfil uma vez na ativação e deixa o sistema em paz, o que é o ideal em servidores de produção onde a consistência é mais importante do que a poupança de energia. O ajuste dinâmico monitoriza a utilização do disco, da rede e da carga em tempo real e ajusta as definições em tempo real. Os perfis de desempenho desativam o ajuste dinâmico por predefinição para evitar a sobrecarga da monitorização.

Escolher o perfil certo para a sua carga de trabalho

O Tuned fornece uma dúzia de perfis que abrangem as cargas de trabalho mais comuns. Escolha aquele que corresponde ao que o servidor realmente faz, em vez de deixar o balanced .

Para motores de base de dados específicos, o tuned também é fornecido postgresql, mssql, e oracle perfis que vão além throughput-performance ajustando a memória partilhada e os parâmetros do agendador do kernel para esses motores.

Em servidores com vários soquetes, a topologia NUMA é importante. O acesso à memória de nós remotos pode ser duas a três vezes mais lento do que o acesso local. Para cargas de trabalho em que a latência é crítica em máquinas com dois soquetes, desative o balanceamento NUMA automático no perfil e atribua processos a nós específicos manualmente.

Instalação e aplicação de perfis

Instale o tuned no RHEL, Rocky, AlmaLinux ou Fedora:

dnf install tuned
systemctl enable --now tuned

No Debian e no Ubuntu, o pacote também se chama tuned e instala-se através de apt. Se power-profiles-daemon já estiver em execução, oculte-o para evitar conflitos:

systemctl mask --now power-profiles-daemon

Liste os perfis disponíveis, pergunte ao tuned o que ele recomenda para o hardware, aplique um perfil e verifique-o:

tuned-adm list
tuned-adm recommend
tuned-adm profile throughput-performance
tuned-adm verify

O perfil ativo é armazenado em /etc/tuned/active_profile e persiste após reinicializações. Para remover totalmente o ajuste e medir a linha de base, execute tuned-adm off.

Criação de um perfil personalizado para cargas de trabalho de IA, ML e largura de banda elevada

Quando os perfis padrão o levarem a 90% do caminho, crie um perfil personalizado que herde do que mais se aproxima e substitua os parâmetros restantes. Comece com um diretório e um ficheiro de configuração:

mkdir -p /etc/tuned/ai-gpu
cat > /etc/tuned/ai-gpu/tuned.conf <<'EOF'
[main]
summary=Custom profile for GPU training with high-bandwidth networking
include=accelerator-performance
 
[cpu]
governor=performance
 
[sysctl]
kernel.numa_balancing=0
net.core.rmem_max=268435456
net.core.wmem_max=268435456
net.ipv4.tcp_rmem=4096 87380 268435456
net.ipv4.tcp_wmem=4096 65536 268435456
 
[vm]
transparent_hugepages=never
 
[bootloader]
cmdline=hugepagesz=2M hugepages=16384 <a target="_blank" rel="noopener noreferrer" href="https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit">iommu</a>=pt
EOF
 
tuned-adm profile ai-gpu

As escolhas-chave aqui:

• numa_balancing=0 impede o kernel de migrar memória entre sockets durante as execuções de treino, uma fonte comum de lentidão em sistemas com GPU de dois sockets.
• O rmem_max e tcp_rmem aumentam o limite máximo do buffer do socket para 256 MB. Em interligações de 25G, 40G ou 100G entre nós de treino, os tamanhos padrão do buffer limitam a taxa de transferência para um valor bem abaixo da taxa de linha.
• transparent_hugepages=never elimina a variação de latência que o THP causa em frameworks como o PyTorch e o TensorFlow, que alocam tensores de grande dimensão.
• iommu=pt coloca o IOMMU no modo de passagem, necessário para a passagem de GPU e NIC, e reduz a sobrecarga no DMA bare-metal.

Qualquer coisa abaixo de [bootloader] requer uma reinicialização. Após ativar o perfil, execute tuned-adm verify para confirmar que os parâmetros de tempo de execução foram aplicados e verifique journalctl -u tuned se há erros. Faça um benchmark antes e depois com iostat -xz, numastate a ferramenta de carga de trabalho relevante (iperf3, fioou a execução de treino real).

Uma compensação que vale a pena esclarecer: desativar as medidas de segurança da CPU proporciona um ganho de cerca de 3 a 8% nas cargas de trabalho da GPU, mas custa 15 a 30% nas cargas de trabalho com padrões intensivos de chamadas de sistema. Decida com base no modelo de ameaças da máquina. Dentro de um cluster de treino dedicado protegido por uma firewall, a matemática geralmente favorece a desativação dessas medidas. Num host multi-tenant, mantenha-as ativadas.

Gerir perfis numa frota de servidores

A aplicação manual do tuned deixa de ser viável quando se ultrapassa um pequeno número de servidores. O Ansible lida com isto de forma eficiente. Um único playbook instala o tuned, cria diretórios de perfis personalizados em /etc/tuned/ através do template módulo e aplica o perfil certo por grupo de inventário.

Mapeie perfis para funções no inventário:

• Nós de GPU e IA: accelerator-performance, ou um perfil personalizado que herda dele
• Servidores de base de dados: throughput-performance ou o perfil específico do motor
• Nós CDN e de borda que enviam tráfego de alta largura de banda: network-throughput
• Servidores API e web atrás de um balanceador de carga: network-latency
• VPS e máquinas convidadas KVM: virtual-guest
• Hosts de hipervisor: virtual-host

O desvio é o verdadeiro problema operacional. sysctl , atualizações de pacotes que incluem novos padrões ou outra ferramenta de gestão de configuração a interferir com o tuned farão com que as definições se desviem do que o perfil indica. Agende uma tarefa Ansible para ser executada tuned-adm active e tuned-adm verify no cron e a alertar em caso de falhas. Verifique /var/log/tuned/tuned.log pelas linhas «Verificação falhou».

Conclusão

O tuned elimina grande parte das suposições do ajuste do kernel e do sysctl. As predefinições são suficientes para uso geral, e os perfis específicos para cargas de trabalho, como accelerator-performance, throughput-performance, e network-throughput levam-no quase até à otimização sem escrever um único ficheiro de configuração.

• Escolha o perfil padrão mais próximo, execute tuned-adm verifye, em seguida, faça um benchmark
• Crie perfis personalizados herdando de um perfil padrão e substituindo apenas o que for necessário
• Seja criterioso quanto ao equilíbrio NUMA, às páginas gigantes e aos tamanhos dos buffers de rede em máquinas com GPU e de alta largura de banda
• Implemente com o Ansible e faça auditorias regulares para detetar desvios

Precisa de capacidade bare-metal com margem de largura de banda para utilizar efetivamente estas configurações? Fale com a FDC sobre servidores dedicados concebidos para cargas de trabalho de alto rendimento e GPU.