RcvPruned MIB is incremented just before the kernel leaves the
tcp_prune_queue() function, resulting in dropping of packets.
Prior to this, the kernel will have tries to collapse data in socket buffers (squeeze data together and discard overheads). Data will first be pruned from the out-of-order queue, then from the regular in-order queue.
This means your sockets are facing memory pressure, likely your socket buffers are not big enough.
You said above:
net.ipv4.tcp_rmem = 183936 245248 367872
The maximum is nowhere near big enough. Increase it to 10x that value to give the kernel room to increase socket memory as it wants to. Increase
net.core.rmem_max as well, as that is used in TCP window accounting.
I'm not sure how you've calculated your buffer sizes, but if you're load balancing lots of small-packet traffic (like HTTP requests) then most of your buffer usage will be overhead.
Depending on which kernel you're running, there is different accounting for this. The "old" method makes some inaccurate assumptions but turns out to be quite forgiving, the "new" method accounts accurately and requires buffers to be sized a bit larger than previous.
The patch set which changes this focuses around the calculation of
skb->truesize and IIRC was applied sometime between kernel 3.0 and 3.10.
You also will want to check the value of
net.ipv4.tcp_mem and make sure you're not restricting the amount of total memory TCP is allowed to use. This tunable is measured in pages, not bytes. Personally I just make all values so big they'll never be hit. Buy more memory as required.