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

Question

Estou fazendo algum planejamento de capacidade e queria saber se existe uma fórmula que eu poderia 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 acho que aparecerão na fórmula são:

• net.ipv4.tcp_wmem do sysctl (min ou valor padrão)
• net.ipv4.tcp_rmem do sysctl (min ou valor padrão)
• o tamanho das estruturas de dados sock, sock_common, proto e outras por socket.

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

    

Answer 1

Se você puder modificar o código-fonte, use dados de rusagem para medir o RSS e registre quantas conexões TCP estão em jogo 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 em lsof -i .

Colete esses dados a cada minuto enquanto o seu aplicativo passa pela carga de pico 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 de RAM do kernel, embora as estruturas de dados tcp devam ser previsíveis e calculáveis com antecedência. De qualquer forma, dê uma olhada nesta questão link para mais informações sobre o ajuste TCP e como obter uma visão clara do que está acontecendo na pilha de rede.

    

Answer 2

tcp_mem é mais importante porque define como a pilha tcp deve se comportar quando se trata de uso da memória. O buffer de envio e recebimento da IMO deve ser um múltiplo de tcp_mem. Aqui está um link para uma fórmula para receber o buffer: link . Resumindo:

The overhead is: window/2^tcp_adv_win_scale (tcp_adv_win_scale default is 2) So for linux default parameters for the recieve window (tcp_rmem): 87380 - (87380 / 2^2) = 65536. Given a transatlantic link (150 ms RTT), the maximum performance ends up at: 65536/0.150 = 436906 bytes/s or about 400 kbyte/s, which is really slow today. With the increased default size: (873800 - 873800/2^2)/0.150 = 4369000 bytes/s, or about 4Mbytes/s, which is resonable for a modern network. And note that this is the default, if the sender is configured with a larger window size it will happily scale up to 10 times this (8738000*0.75/0.150 = ~40Mbytes/s), pretty good for a modern network.

Aqui está o que o artigo diz sobre o tcp_mem:

What you remove is an artificial limit to tcp performance, without that limit you are bounded by the available end-to-end bandwidth and loss. So you might end up saturating your uplink more effectively, but tcp is good at handling this.

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

Você pode monitorar a pilha de rede com:

grep skbuff /proc/slabinfo

    

Answer 3

David forneceu uma resposta muito boa para a pergunta, a menos que você esteja usando exclusivamente LFNs , então, mesmo em um servidor baseado em eventos, os buffers TCP provavelmente serão apenas uma pequena parte da área ocupada por conexão.

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