On 12/10/2010 12:28 PM, Steve Davies wrote: > On 10 December 2010 17:33, Steve Davies <[email protected]> wrote: >> On 10 December 2010 17:21, Shaun Ruffell <[email protected]> wrote: >>> On 12/10/2010 11:02 AM, Steve Davies wrote: >>>> On 10 December 2010 16:45, Steve Davies <[email protected]> wrote: >>>>> Hi, >>>>> >>>>> On one of our asterisk systems that is quite busy, we are seeing the >>>>> following from 'netstat -s': >>>>> >>>>> Udp: >>>>> 17725210 packets received >>>>> 36547 packets to unknown port received. >>>>> 44017 packet receive errors >>>>> 17101174 packets sent >>>>> RcvbufErrors: 44017 <--- this >>>>> >>>> [snip] >>>>> >>>>> net.core.rmem_max = 1048575 >>>>> net.core.wmem_max = 1048575 >>>>> net.core.rmem_default = 1048575 >>>>> net.core.wmem_default = 1048575 >>>>> net.core.optmem_max = 1048575 >>>>> net.core.netdev_max_backlog = 10000 >>>>> >>>> >>>> Additional question - Do I need to restart Asterisk for these settings >>>> to apply to SIP? I have not done so yet, and further reading suggests >>>> that this is a per-process buffer and may be assigned when the >>>> listener is created. >>>> >>> >>> I had to double check myself in the kernel sources (in >>> net/core/sock.c:sock_init_data), but yes you will need to recreate the >>> socket for the rmem_default option to take effect. >>> >>> I was just about to ask if changing the sysctl changed the frequency >>> that you see the error counter increment when I saw your follow on. >>> >>> Cheers, >>> Shaun >> >> Thanks for making the extra effort Shaun :) I will restart Asterisk >> when I get a chance, and re-check. >> >> Regards, >> Steve >> > > False alarm? > > FYI, it seems that the issue is not at-all what we thought. > > It transpires that the unit is an old Asterisk 1.2 system, and that > the DNS server that the unit had been pointed to had been taken out of > service. This caused lots of threads to back-up while attempting to > resolve things, and this dragged down the whole of asterisk, seemingly > to the point where it was not reading UDP data out of its buffers fast > enough! >
Ahh...this makes complete sense then. Thanks for following up. -- Shaun Ruffell Digium, Inc. | Linux Kernel Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
