[OpenSIPS-Users] Fine tuning high CPS and msyql queries

[David Villasmil]

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.

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.


On Sat, 13 Jun 2020 at 00:28, Alex Balashov <abalashov at evaristesys.com>
wrote:

> 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 at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200613/a767c952/attachment.html>