O TCP RcvPruned MIB é incrementado pouco antes de o kernel deixar a função tcp_prune_queue() , resultando na eliminação de pacotes.
Antes disso, o kernel terá tentativas de recolher dados em buffers de soquete (juntar dados e descartar despesas gerais). Primeiro, os dados serão removidos da fila fora de ordem e depois da fila normal em ordem.
Isso significa que seus soquetes estão enfrentando pressão de memória, provavelmente seus buffers de soquete não são grandes o suficiente.
Você disse acima:
net.ipv4.tcp_rmem = 183936 245248 367872
O máximo está longe de ser grande o suficiente. Aumente para 10x esse valor para dar espaço ao kernel para aumentar a memória do soquete como quiser. Aumente net.core.rmem_max , como é usado na contabilidade da janela TCP.
Não sei ao certo como você calculou o tamanho dos seus buffers, mas se você fizer o balanceamento de carga com lotes de tráfego de pacotes pequenos (como solicitações HTTP), a maior parte do uso do buffer ficará sobrecarregada.
Dependendo do kernel que você está executando, há uma explicação diferente para isso. O método "antigo" faz algumas suposições imprecisas, mas acaba por ser bastante indulgente, o "novo" método de contas com precisão e requer buffers para ser dimensionado um pouco maior que o anterior.
O conjunto de correções que muda isso se concentra em torno do cálculo de skb->truesize e IIRC foi aplicado em algum momento entre o kernel 3.0 e 3.10.
Você também desejará verificar o valor de net.ipv4.tcp_mem e certificar-se de não restringir a quantidade de memória total que o TCP pode usar. Este ajuste é medido em páginas , não em bytes. Pessoalmente eu apenas faço todos os valores tão grandes que nunca serão atingidos. Compre mais memória conforme necessário.