[Home]

Summary:ASTERISK-15535: after a few minutes it takes down the server
Reporter:Private Name (falves11)Labels:
Date Opened:2010-01-27 18:03:33.000-0600Date Closed:2010-03-18 15:00:35
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Versions 1.6.X has a problem with UDP ports. I use SIP timers in my sip.conf, so I imagine it its related. After a few minutes of intense traffic, this linux command ("lsof -i | wc -l") shoots to 30.000+ and in fact kills the machine, because the Kernel spends most of the time in a single function, sock_poll. This is what the Parallels engineers have found:
"this function finds a free socket that might be used for the data transfer. Because your node have about 5000 already used sockets finding free socket might take relatively big time. As far as I understand if system is unable to find the free socket fast enough it just drops UDP packet because there is no delivery guarantee for this protocol."

****** ADDITIONAL INFORMATION ******

After a while it seems that Asterisk stopped talking to the network, but in fact, it just killed the kernel. This does not happen at all in version 1.4

I can reproduce it but have no idea how to determine where the problem is. In order to reproduce I need to reinstall 1.6.1, and let it run. Don't know what else to do.
Comments:By: Private Name (falves11) 2010-01-28 02:54:08.000-0600

I realize that I reported this issue some months ago, so long ago, that I had forgotten, because I went back to version 1.4. I wonder how can we advance this issue. It is easily reproducible, in less than 10 mins the UDP port count goes to 30.0000 in my server. If is there anything I can do to help figuring this out, let me know. This is the main showstopper between 1.6.X and any business use. So far the entire branch 1.6.X cannot be used for any real business. We can do much better as a community.

By: Leif Madsen (lmadsen) 2010-03-18 15:00:34

Closing this issue as a duplicate.