Re: [SR-Users] Kamailio consuming UDP packets very slowly leading to high RECV - Q

2018-08-29 Thread sagar malam
Hello Henning, Thanks for your inputs. Issue got fixed after upgrading kernel version to 4.18.5( latest one). So there was something wrong in Kernel 4.16.7. On Wed, Aug 29, 2018 at 1:09 AM Henning Westerholt wrote: > Am Dienstag, 28. August 2018, 13:52:09 CEST schrieb sagar malam: > > I agree

Re: [SR-Users] Kamailio consuming UDP packets very slowly leading to high RECV - Q

2018-08-28 Thread Henning Westerholt
Am Dienstag, 28. August 2018, 13:52:09 CEST schrieb sagar malam: > I agree but i want to find root cause of this problem.Can you suggest me > what next i need to look at OS level ? Hello Sagar, as already suggested - I would try to sort out the other variables in this setup: - compare the serve

Re: [SR-Users] Kamailio consuming UDP packets very slowly leading to high RECV - Q

2018-08-28 Thread Daniel-Constantin Mierla
Well, I can't really say what limits selinux puts in place or other CentOS specific apps, but I encountered various strange situations where no centos sysadmin I interacted with could give a solution, even with selinux disabled, so could be something else... Coming in my mind: limit on number of n

Re: [SR-Users] Kamailio consuming UDP packets very slowly leading to high RECV - Q

2018-08-28 Thread sagar malam
Alex, I agree but i want to find root cause of this problem.Can you suggest me what next i need to look at OS level ? Thanks On Tue, Aug 28, 2018 at 5:15 PM Alex Balashov wrote: > On Tue, Aug 28, 2018 at 05:12:01PM +0530, sagar malam wrote: > > > Further i have same Kamailio script in another se

Re: [SR-Users] Kamailio consuming UDP packets very slowly leading to high RECV - Q

2018-08-28 Thread Alex Balashov
On Tue, Aug 28, 2018 at 05:12:01PM +0530, sagar malam wrote: > Further i have same Kamailio script in another server and i am not > facing this issue there. That pretty well points to the problem being caused by the runtime environment rather than the Kamailio config or anything it does. -- Ale

Re: [SR-Users] Kamailio consuming UDP packets very slowly leading to high RECV - Q

2018-08-28 Thread Alex Balashov
On Tue, Aug 28, 2018 at 01:31:04PM +0200, Daniel-Constantin Mierla wrote: > if you have performance issues just with a very simple config sending > a stateless sip reply, then check your system/firewall > configuration/limits. Specially on centos, I have seen a lot of > restrictive traffic rates l

Re: [SR-Users] Kamailio consuming UDP packets very slowly leading to high RECV - Q

2018-08-28 Thread sagar malam
Thanks for prompt response. Some more information : We are running it on virtual machine(Xenserver). Selinux and IPtables are disabled.I will check if VM platform is putting some limits or not. Further i have same Kamailio script in another server and i am not facing this issue there. OS max UD

Re: [SR-Users] Kamailio consuming UDP packets very slowly leading to high RECV - Q

2018-08-28 Thread Daniel-Constantin Mierla
Hello, On 28.08.18 12:42, sagar malam wrote: > Hello, > > I am using Kamailio as a SIP proxy.So it receives SIP packet from > internet and forwards it to FS servers in local network.When i execute > "ss" command i see very high value in RECV-Q column.I THINK IT IS NOT > NORMAL.PLEASE CORRECT ME I

Re: [SR-Users] Kamailio consuming UDP packets very slowly leading to high RECV - Q

2018-08-28 Thread Alex Balashov
No, this is not normal. But you almost certainly have some external I/O operation which is blocking the worker thread. There isn't much explanation otherwise. This article (disclaimer: I wrote it) may help: http://www.evaristesys.com/blog/tuning-kamailio-for-high-throughput-and-performance/ --

[SR-Users] Kamailio consuming UDP packets very slowly leading to high RECV - Q

2018-08-28 Thread sagar malam
Hello, I am using Kamailio as a SIP proxy.So it receives SIP packet from internet and forwards it to FS servers in local network.When i execute "ss" command i see very high value in RECV-Q column.I THINK IT IS NOT NORMAL.PLEASE CORRECT ME IF I AM WRONG.