[asterisk-users] UDP buffer overflows?

[Steve Davies]

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!

Thanks,
Steve