Otimizações no Proxmox

De Wiki Projeto Root
Ir para navegação Ir para pesquisar

Sobre

Olá! Visitante, reunimos aqui, informações sobre como realizar otimizações no sistema para que o Proxmox tenha mais performance.

Fontes: https://pve.proxmox.com/pve-docs/

Conceitos

Para otimizar o Proxmox para ter maior performance no hardware, você pode seguir várias práticas recomendadas e ajustes. Aqui estão algumas dicas:

Yellowpin.svg Nota: Tenha um Hardware Compatível e Adequado

CPU: Utilize processadores com suporte a virtualização (Intel VT-x ou AMD-V).

Memória RAM: Certifique-se de ter memória suficiente para suportar suas VMs. Utilize memória RAM com ECC (Error-Correcting Code) para maior confiabilidade.

Armazenamento: Utilize discos SSD ou NVMe para armazenamento de VMs, já que são muito mais rápidos que HDDs tradicionais.

Rede: Configure placas de rede de alta performance (10GbE ou superior) e use LACP (Link Aggregation Control Protocol) para aumentar a largura de banda e redundância.


Configuração do Proxmox

Kernel: Utilize a versão mais recente do kernel do Proxmox para aproveitar as últimas melhorias e correções de segurança.

Cgroups e NUMA: Habilite cgroups e configure NUMA (Non-Uniform Memory Access) corretamente, especialmente em sistemas com múltiplas CPUs.

I/O Threads: Habilite e configure I/O threads nas VMs para melhorar o desempenho de disco.

Armazenamento

ZFS: Se utilizar ZFS, ajuste os parâmetros de memória ARC e considere usar SSDs para cache (ZIL e L2ARC).

LVM: Use LVM sobre discos rápidos (preferencialmente SSDs) e configure o thin provisioning para economizar espaço.

Configuração das VMs

Virtio Drivers: Utilize drivers Virtio para disco e rede nas VMs para melhor performance.

Recursos Alocados: Evite superprovisionar CPU e memória. Alocar mais recursos do que o disponível no host pode degradar a performance.

Ballooning: Habilite o ballooning para gerenciar dinamicamente a memória entre as VMs.

CPU Pinning: Configure o pinning de CPU para garantir que certas VMs utilizem CPUs específicas, reduzindo a latência.

Rede

Bridged Networking: Utilize a configuração de bridge networking para reduzir a latência e aumentar a performance de rede.

Offloading: Habilite funções de offloading na placa de rede, como checksum e segmentation offloading, para reduzir a carga na CPU.

Monitoramento e Ajustes Contínuos

Monitoramento: Utilize ferramentas como htop, iotop, vmstat e o monitoramento integrado do Proxmox para observar o uso de recursos e identificar gargalos.

Ajustes: Baseado nos dados de monitoramento, ajuste a configuração das VMs e do host para otimizar a performance.

Backup e Manutenção

Snapshots e Backups: Utilize snapshots com moderação, pois podem impactar na performance. Configure backups regulares sem afetar a performance durante horários de pico.

Atualizações: Mantenha o Proxmox e os sistemas das VMs sempre atualizados com as últimas versões e patches de segurança. Seguindo essas práticas, você deve conseguir extrair o máximo de performance do seu ambiente Proxmox.

Ajustes nas Interfaces de Rede

Habilite funções de offloading na placa de rede, como checksum e segmentation offloading, para reduzir a carga na CPU, no Proxmox, as opções de offloading de rede não são configuradas diretamente através da interface web do Proxmox. Em vez disso, você precisa configurá-las manualmente no sistema operacional subjacente (Debian) utilizando ferramentas de rede como ethtool.


Yellowpin.svg Nota: O descarregamento de segmentação (TSO) é uma técnica de otimização que reduz a sobrecarga da CPU em operações de rede relacionadas a TCP/IP. Com o TSO ativado, um controlador de Internet de rede (NIC) divide grandes pedaços de dados que viajam por uma rede em segmentos TCP menores. Sem o TSO, a segmentação é realizada pela CPU, o que gera um overhead. TSO também é conhecido como LSO (Large Segment Offload).
Yellowpin.svg Nota: Generic Segmentation Offload (GSO) é uma implementação de software amplamente usada do TCP Segmentation Offload (TSO), que reduz a sobrecarga de processamento por pacote. Assim como o TSO, o GSO ganha desempenho ao permitir que aplicativos de camada superior processem um número menor de pacotes grandes (por exemplo, tamanho de MTU de 64 KB), em vez de processar um número maior de pacotes pequenos (por exemplo, tamanho de MTU de 1500 B), reduzindo assim a sobrecarga por pacote.
Yellowpin.svg Nota: Generic Receive Offload (GRO) é uma técnica de offloading baseada em SW amplamente usada para reduzir as sobrecargas de processamento por pacote. Ao remontar pacotes pequenos em pacotes maiores, o GRO permite que os aplicativos processem menos pacotes grandes diretamente, reduzindo assim o número de pacotes a serem processados. Para beneficiar aplicativos baseados em DPDK, como o Open vSwitch, o DPDK também fornece sua própria implementação de GRO. No DPDK, o GRO é implementado como uma biblioteca autônoma. Os aplicativos usam explicitamente a biblioteca GRO para remontar pacotes.
Yellowpin.svg Nota: TCP Checksum Offload (IPv4 and IPv6),esta configuração permite que o adaptador verifique o checksum TCP de pacotes de entrada/saída (RX/TX) e calcule o checksum TCP de pacotes de entrada e saída. Este recurso melhora o desempenho de recepção e transmissão e reduz a utilização da CPU. Com o Offloading desativado, o sistema operacional verifica a soma de verificação do TCP. Com o Offloading ativado, o adaptador conclui a verificação do sistema operacional.


Edite o arquivo /etc/network/interfaces ou crie um script para ser executado na inicialização. Adicione as seguintes linhas ao arquivo /etc/network/interfaces (substitua ens1f0 e ens1f1 pelos nomes das suas interfaces de redes):

nano /etc/network/interfaces
auto lo
iface lo inet loopback

iface ens1f0 inet manual
iface ens1f1 inet manual

auto vmbr0
iface vmbr0 inet manual
       bridge-ports ens1f0
       bridge-stp off
       bridge-fd 0
       bridge-vlan-aware yes
       bridge-vids 2-4094
       post-up /sbin/ethtool -K ens1f0 tso on
       post-up /sbin/ethtool -K ens1f0 gso on
       post-up /sbin/ethtool -K ens1f0 gro on
       post-up /sbin/ethtool -K ens1f0 rx on
       post-up /sbin/ethtool -K ens1f0 tx on

auto vmbr0.800
iface vmbr0.800 inet static
       address 10.10.80.101/24
       gateway 10.10.80.1
# Interface de Gerência

auto vmbr1
iface vmbr1 inet manual
       bridge-ports ens1f1
       bridge-stp off
       bridge-fd 0
       bridge-vlan-aware yes
       bridge-vids 2-4094
       post-up /sbin/ethtool -K ens1f1 tso on
       post-up /sbin/ethtool -K ens1f1 gso on
       post-up /sbin/ethtool -K ens1f1 gro on
       post-up /sbin/ethtool -K ens1f1 rx on
       post-up /sbin/ethtool -K ens1f1 tx on
# Interface LAN

source /etc/network/interfaces.d/*
Yellowpin.svg Nota: Nesse arquivo, as configurações de offloading para ens1f0 e ens1f1 são aplicadas usando os comandos ethtool na seção post-up. Isso garante que as configurações de offloading sejam aplicadas cada vez que as interfaces são ativadas.

Após fazer essas alterações, reinicie as interfaces de rede para aplicar as novas configurações:

ifdown vmbr0 && ifup vmbr0
ifdown vmbr1 && ifup vmbr1

Ajustes no Kernel

vm.swappiness: Controla a tendência do kernel de trocar processos da memória RAM para o swap. Valores mais baixos (por exemplo, 10) reduzem a utilização de swap e mantêm mais dados na memória RAM. Para servidores, um valor entre 10 e 20 é geralmente recomendado.

vm.dirty_ratio: Define o percentual de memória total do sistema que pode conter dados sujos (dados que precisam ser escritos no disco) antes que o kernel comece a forçar a gravação no disco. Um valor de 10 significa que quando 10% da memória está suja, o kernel começa a escrever os dados no disco.

vm.dirty_background_ratio: Define o percentual de memória total do sistema que pode conter dados sujos antes que o kernel comece a escrever esses dados no disco em segundo plano. Um valor de 5 significa que quando 5% da memória está suja, o kernel começa a gravar os dados no disco em segundo plano.

vm.min_free_kbytes: Define a quantidade mínima de memória que o kernel deve tentar manter livre. Ajustar isso pode ajudar a evitar que o sistema fique sem memória disponível para tarefas críticas.

vm.overcommit_memory e vm.overcommit_ratio: Controlam como o kernel lida com a alocação de memória que excede a memória física disponível. Ajustar esses parâmetros pode ajudar a evitar que o sistema fique sem memória.

Hugepages: são páginas de memória grandes que podem ser usadas para melhorar o desempenho de aplicativos que fazem uso intensivo de memória, como bancos de dados e servidores de virtualização. As páginas de memória padrão no Linux têm 4KB, enquanto as hugepages têm 2MB ou mais, dependendo da arquitetura. Usar hugepages pode reduzir a sobrecarga de gerenciamento de memória e melhorar a performance de I/O de memória.

net.core.rmem_max: Define o tamanho máximo do buffer de recepção (receiving buffer) de um socket em bytes. Esse valor determina o quanto de dados pode ser bufferizado para recepção em um socket de rede. Um valor maior permite que o sistema bufferize mais dados recebidos, o que pode ser útil em redes de alta velocidade para evitar perda de pacotes e melhorar o desempenho de transferência de dados.

net.core.wmem_max: Define o tamanho máximo do buffer de transmissão (sending buffer) de um socket em bytes. Esse valor determina o quanto de dados pode ser bufferizado para envio em um socket de rede. Um valor maior permite que o sistema bufferize mais dados a serem enviados, o que pode ser útil em redes de alta velocidade para melhorar a taxa de transferência de dados.

net.ipv4.tcp_rmem: Define os valores mínimos, padrão e máximos do buffer de recepção para conexões TCP. O primeiro valor (4096) garante que o buffer de recepção nunca será menor que 4KB, o segundo valor (87380) é o tamanho padrão do buffer de recepção, o terceiro valor (16777216) permite que o buffer de recepção possa crescer até 16MB se necessário, dependendo da carga de rede e da quantidade de memória disponível.

net.ipv4.tcp_wmem: Define os valores mínimos, padrão e máximos do buffer de transmissão para conexões TCP. O primeiro valor (4096) garante que o buffer de transmissão nunca será menor que 4KB, o segundo valor (65536) é o tamanho padrão do buffer de transmissão, o terceiro valor (16777216) permite que o buffer de transmissão possa crescer até 16MB se necessário, dependendo da carga de rede e da quantidade de memória disponível.

net.ipv4.tcp_window_scaling: Habilita o uso de escala de janela TCP para conexões TCP. A escala de janela TCP é uma opção que permite aumentar o tamanho da janela TCP além do limite padrão de 64KB. Isso é feito utilizando um fator de escala que pode aumentar significativamente o tamanho da janela, permitindo maiores taxas de transferência em redes de alta latência e alta largura de banda. Configurar este parâmetro como 1 habilita a escala de janela TCP, permitindo que o sistema aproveite melhor a largura de banda disponível em redes de alta velocidade.


nano /etc/sysctl.conf
#### Otimização Proxmox 
vm.swappiness=10
vm.dirty_ratio=10
vm.dirty_background_ratio=5
vm.min_free_kbytes=65536
vm.overcommit_memory=1
vm.overcommit_ratio=50
vm.nr_hugepages=2048
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_window_scaling=1

Aplicar com:

sysctl -p
Yellowpin.svg Nota: Recomendável reiniciar o servidor para uma aplicabilidade correta.