<div dir="ltr"><div dir="ltr">On Fri, Jun 12, 2020 at 5:23 PM Alex Balashov <<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">One should see the forest for the trees, instead of cultivating a myopic <br>
preoccupation with short-term, stop-gap solutions.<br></blockquote><div><br></div><div>Understanding that text lacks tone, this a rather offputting comment for a mailing list intended to help users. 

I appreciate your time and feedback, there's no need to be insulting. 

Perhaps you could stop assuming what my preoccupations and scope of vision are and concentrate on the problem and the solution? The question now is why increasing buffers made any difference at all.</div><div><br></div><div><div>You suggested to "Monitor your receive queue scrupulously at a very high timing resolution". How do I do this?</div><div></div></div><div><br></div><div>You propose there is a pathological issue and the increased buffer size is masking it. How do I determine what that issue is?</div><div><br></div><div>I've asked repeatedly about children, shared memory, process memory, timer_partitions, etc. but the only answers have been "try more". I've been trying more and less of these things two weeks and changing the buffers was the only thing that appeared to have any immediate impact. How do I know when enough is enough versus too much? </div><div><br></div><div>Note, there have been no memory-related log messages. The 16-thread servers have 48GB RAM and the 8-thread servers have 16GB. I'm happy to give all that to OpenSIPS once I know the right way to carve it up.</div><div><br></div><div>Should I even be using 2.4?</div><div><br></div></div></div>