Por que mudar o net.inet.tcp.tcbhashsize no FreeBSD?

Em praticamente todos os documentos de ajuste de rede do FreeBSD, posso encontrar:

# /boot/loader.conf
net.inet.tcp.tcbhashsize=4096

Isso geralmente é associado a alguma declaração inútil, como "Ajuste da tabela de hash do bloco de controle TCP" ou "Configure isso para um valor razoável". man 4 tcptambém não ajuda muito:

tcbhashsize         Size of the TCP control-block hash table (read-only).
                    This may be tuned using the kernel option TCBHASHSIZE
                    or by setting net.inet.tcp.tcbhashsize in the
                    loader(8).

O único documento que posso encontrar sobre esse assunto misterioso é a subseção Pesquisa de bloco de controle de protocolo abaixo da Camada de transporte na Otimização da pilha de IP e TCP do FreeBSD , mas sua descrição é mais sobre possíveis gargalos na sua utilização. Parece ligado a combinar novos segmentos TCP com seus soquetes de escuta, mas não sei como.

Para que exatamente o bloco de controle TCP é usado? Por que você deseja definir seu tamanho de hash para 4096 ou qualquer outro número específico?

freebsd performance-tuning sysctl

— sh-beta
fonte

+1, pergunta muito interessante!

— Janne Pikkarainen

AFAIK, todas as informações para entrega de pacotes no soquete apropriado estão disponíveis inpcbapenas por via .

— SaveTheRbtz

É mais como uma questão de ciência da computação. Especialmente se você quiser explorar tabelas de hash e notações grandes .

A resposta é:
Se você está lidando com muitas sessões TCP em sever, realmente deseja consultar os parâmetros tcp da conexão no tempo O (1) em vez de O (n). O FreeBSD usa encadeamento para resolver colisões de tabelas de hash. Portanto, se houver muita conexão, haverá muitas colisões e, em vez da pesquisa de tabela de hash O (1), você precisará fazer uma pesquisa de cadeia linear com complexidade O (n).

O parâmetro que você mencionou - tcbhashsizeé basicamente o número de buckets na tabela de hash.
Em nossos servidores, é definido com valores bastante altos 16384e até mais altos. Com essa configuração, estamos lidando com cerca de 60.000 conexões por servidor.

Cada entrada na tabela de hash por si só atualmente em x86_64 usa 252 bytes ( tcp_inpcb) + 688 bytes ( tcpcb) de memória do kernel para cada entrada (o tamanho do kmem é 512G em amd64 desde 7.2+ IIRC). Pode ser visualizado via vmstat -z.

Sobre a estrutura do bloco TCP Control, você pode ler fontes do FreeBSD: tcp_var.h ou ler TCP / IP Illustrated, Volume 2: A Implementação Por Gary R. Wright, W. Richard Stevens

— SaveTheRbtz
fonte

Era tudo embaçado, mas agora com este cabeçalho C obscura tudo é claro;)

— gparent

Entendo por que aumentar o número de buckets em uma hashtable ajudaria o desempenho das pesquisas nesses buckets; eu não sabia que isso era realmente o que esse valor estava fazendo. Se esta é uma tabela de buckets, suponho que o TCPCB seja realmente o local onde as informações do soquete são armazenadas para que os segmentos TCP possam corresponder ao receptor apropriado. Você pode confirmar isso? Além disso, parte do objetivo desses sites é agregar informações; portanto, as respostas "Leia a fonte" ou "Leia um livro" não são muito úteis.

— sh-beta

Como você chegou ao seu ajuste de 16384? Porquê isso? E o que você está sacrificando por esse valor (presumo a memória do kernel, mas quanto?)? Se fosse uma vitória de desempenho grátis, eu gostaria de pensar que seria o padrão. Certamente custa algo.

— sh-beta

Na minha opinião, esse valor deve ser definido um pouco próximo ao número de conexões simultâneas que este servidor está disposto a lidar. PS. Você realmente quer se tornar um especialista em alguma área sem ler fontes / livros? =)

— SaveTheRbtz

@SaveTheRbtz Eu abomino essa noção de que, se você usa uma tecnologia, precisa parar de fazer perguntas ou se tornar tão especialista no código que pode recitar o objetivo preciso de cada estrutura e função individual na pilha de rede. O objetivo do StackExchange é trocar conhecimento. Sou especialista em algumas coisas e não em outras. Essa linha é determinada pelo meu trabalho, onde tenho que escolher cuidadosamente onde passo meu tempo. Mas isso não significa que estou satisfeito em simplesmente aceitar "conselhos" de ajuste que parecem ter sido copiados e colados de maneira impensada de um blog para outro.

— sh-beta