On 6/12/20 7:20 PM, Calvin Ellison wrote:
I think the important point here is that the receive buffers are used to hold received data until it is read by the application. In fact, too small of a receive buffer would cause packets to be discarded outright, regardless of how fast the application can respond. Not knowing how large of a buffer is needed was the problem, not the raw processing power. It doesn't matter how fast I can eat if the server only has very small plates to bring the food every trip from the kitchen.
In absolute terms, this is true. But if your kitchen is putting out so much food that not even ~200,000 plates "in flight" will do, you've got a bigger problem to address and adding more plates is just papering it over.
Monitor your receive queue scrupulously at a very high timing resolution. If you found default values for rmem_max to be "absolutely terrible", that means the backlog was increasing monotonically until you ran out of space. If you increase the queue depth, you will be able to prolong this effect for a while.
The kernel's packet queue is a backstop--an emergency release valve, not a main thoroughfare. It's there to help you deal with ephemeral congestion caused by things like periodic big-lock background process contention, scheduler hiccups, disk controller patrol reads, etc. But the base load should result in a long-run queue backlog of zero. Applications which properly cope with their workload don't cause non-trivial packet or connection queueing on the OS side.
-- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
