[asterisk-users] UDP buffer overflows?

[Shaun Ruffell]

On 12/10/2010 12:28 PM, Steve Davies wrote:
> On 10 December 2010 17:33, Steve Davies <davies147 at gmail.com> wrote:
>> On 10 December 2010 17:21, Shaun Ruffell <sruffell at digium.com> wrote:
>>> On 12/10/2010 11:02 AM, Steve Davies wrote:
>>>> On 10 December 2010 16:45, Steve Davies <davies147 at gmail.com> 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