Qual é a fórmula para determinar quanta memória um soquete consome no Linux?

Estou fazendo um planejamento de capacidade e fiquei pensando se existe uma fórmula que eu possa usar para prever (do ponto de vista da memória) quantas conexões TCP eu poderia manipular no meu servidor. No momento, estou preocupado apenas com os requisitos de memória.

Algumas variáveis ​​que eu acho que aparecerão na fórmula são:

• sysctl's net.ipv4.tcp_wmem(valor mínimo ou padrão)
• sysctl's net.ipv4.tcp_rmem(valor mínimo ou padrão)
• o tamanho da meia, sock_common, proto e outras estruturas de dados por soquete.

Não tenho certeza de quanto dos tcp_wmem e tcp_rmem são realmente alocados e quando essa memória é alocada. No momento da criação do soquete? Sob demanda?

Se você pode modificar o código-fonte, use os dados de rusage para medir o RSS e registrar quantas conexões TCP estão em execução no momento da medição.

Se o código-fonte não puder ser alterado, use o RSS do aplicativo de rede conforme relatado por top ou ps e obtenha o número de conexões de rede no momento da medição lsof -i.

Colete esses dados a cada minuto enquanto o aplicativo se move através do pico de carga e, a partir desses dados, você pode criar uma fórmula que relacione o número de conexões ao uso da RAM.

É claro que há muito mais coisas que você pode medir, em particular você pode querer medir o uso da RAM do kernel, embora as estruturas de dados tcp devam ser previsíveis e calculáveis ​​com antecedência. De qualquer forma, consulte esta pergunta /server/10852/what-limits-the-maximum-number-of-connections-on-a-linux-server para obter mais informações sobre o ajuste TCP e como obter uma visão clara do que está acontecendo na pilha de rede.

O tcp_mem é mais importante porque define como a pilha tcp deve se comportar quando se trata de uso de memória. O buffer de envio e recebimento do IMO deve ser um múltiplo de tcp_mem. Aqui está um link para uma fórmula para buffer de recebimento: http://www.acc.umu.se/~maswan/linux-netperf.txt . Em resumo:

A sobrecarga é: window / 2 ^ tcp_adv_win_scale (o padrão tcp_adv_win_scale é 2) Portanto, para os parâmetros padrão do linux para a janela de recebimento (tcp_rmem): 87380 - (87380/2 ^ 2) = 65536. Dado um link transatlântico (RTT de 150 ms), o desempenho máximo termina em: 65536 / 0,150 = 436906 bytes / s ou cerca de 400 kbyte / s, o que é realmente lento hoje. Com o tamanho padrão aumentado: (873800 - 873800/2 ^ 2) /0.150 = 4369000 bytes / s, ou cerca de 4Mbytes / s, que é razoável para uma rede moderna. E observe que esse é o padrão, se o remetente estiver configurado com um tamanho de janela maior, ele aumentará até 10 vezes isso (8738000 * 0,75 / 0,150 = ~ 40Mbytes / s), muito bom para uma rede moderna.

Aqui está o que o artigo diz sobre tcp_mem:

O que você remove é um limite artificial para o desempenho do TCP, sem esse limite você é limitado pela largura de banda e pela perda de ponta a ponta disponíveis. Portanto, você pode saturar seu uplink com mais eficiência, mas o tcp é bom em lidar com isso.

Na IMO, um valor médio maior de tcp_mem acelera a conexão com a perda de menos segurança e aumenta ligeiramente a utilização de memória.

Você pode monitorar a pilha de rede com:

grep skbuff /proc/slabinfo

David forneceu uma resposta muito boa à pergunta, mas, a menos que você esteja usando exclusivamente LFNs , mesmo em um servidor baseado em eventos, os buffers TCP provavelmente serão apenas uma pequena parte do espaço por conexão.

Para o planejamento de capacidade, não há substituto para testar o servidor e calcular a regressão do uso de memória por carga.