<div><div dir="auto">Basically, the application is not processing the received packets as quickly as it should, so the kernel stores the packets in the buffer so it doesn’t have to throw them away.</div><div dir="auto"><br></div><div dir="auto">It’s not so difficult to understand. If this is happening all the time, you won’t solve this by making the buffer bigger. You solve this by figuring out why the application is not processing the packets fast enough.</div><div dir="auto"><br></div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 13 Jun 2020 at 00:28, Alex Balashov <<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On 6/12/20 7:20 PM, Calvin Ellison wrote:<br>
<br>
> I think the important point here is that the receive buffers are used to <br>
> hold received data until it is read by the application. In fact, too <br>
> small of a receive buffer would cause packets to be discarded outright, <br>
> regardless of how fast the application can respond. Not knowing how <br>
> large of a buffer is needed was the problem, not the raw processing <br>
> power. It doesn't matter how fast I can eat if the server only has very <br>
> small plates to bring the food every trip from the kitchen.<br>
<br>
In absolute terms, this is true. But if your kitchen is putting out so <br>
much food that not even ~200,000 plates "in flight" will do, you've got <br>
a bigger problem to address and adding more plates is just papering it <br>
over.<br>
<br>
Monitor your receive queue scrupulously at a very high timing <br>
resolution. If you found default values for rmem_max to be "absolutely <br>
terrible", that means the backlog was increasing monotonically until you <br>
ran out of space. If you increase the queue depth, you will be able to <br>
prolong this effect for a while.<br>
<br>
The kernel's packet queue is a backstop--an emergency release valve, not <br>
a main thoroughfare. It's there to help you deal with ephemeral <br>
congestion caused by things like periodic big-lock background process <br>
contention, scheduler hiccups, disk controller patrol reads, etc.  But <br>
the base load should result in a long-run queue backlog of zero. <br>
Applications which properly cope with their workload don't cause <br>
non-trivial packet or connection queueing on the OS side.<br>
<br>
-- Alex<br>
<br>
-- <br>
Alex Balashov | Principal | Evariste Systems LLC<br>
<br>
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)<br>
Web: <a href="http://www.evaristesys.com/" rel="noreferrer" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" rel="noreferrer" target="_blank">http://www.csrpswitch.com/</a><br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,</div><div><br></div>David Villasmil<div>email: <a href="mailto:david.villasmil.work@gmail.com" target="_blank">david.villasmil.work@gmail.com</a></div><div>phone: +34669448337</div></div></div>