Em termos de nf_conntrack_max , você está limitado apenas pela quantidade de memória do kernel disponível. A memória do kernel não pode ser trocada, então é a RAM real.
TLDR: Em sistemas modernos eu configurei isso para 128k aparentemente sem nenhum efeito negativo.
Outro ajuste que você pode querer ajustar, no entanto, é /proc/sys/net/netfilter/nf_conntrack_buckets . Toda vez que um pacote é examinado, ele é dividido em um dos hashsize buckets (com base no src / dst IP e na porta). Cada bucket contém uma lista vinculada que precisa ser pesquisada para a conexão específica. Aumentar o número de depósitos deve (até certo ponto) diminuir o número de nós na lista vinculada que precisam ser percorridos e, portanto, aumentar o desempenho. A desvantagem é que quanto mais baldes você tiver, maior a probabilidade de baldes vazios. Um balde vazio pega a memória do kernel. É por isso que você não define hashsize = nf_conntrack_max . Não consegui encontrar nenhuma recomendação sobre a configuração do hashsize, exceto a declaração "Em circunstâncias normais, ip_conntrack_max é igual a 8 * hashsize".
Outra coisa a notar é que, quando suas conexões são de curta duração (por exemplo, um servidor da Web), você pode ter muitas conexões no estado TIME_WAIT com entradas correspondentes no hash conntrack. cat /proc/net/nf_conntrack | grep TIME | wc -l ( ip_conntrack em kernels mais antigos) ou iptstate devem informar essa informação. Para reduzir o tempo limite para essas alterações /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait . Você provavelmente também deseja alterar /proc/sys/net/ipv4/tcp_fin_timeout .
Finalmente, se você realmente precisa de desempenho e não pode arcar com a RAM, você pode desativar completamente o firewall e colocar um firewall dedicado a partir do servidor.