|Summary:||ASTERISK-18766: Very poor performance when manager.conf enabled=yes|
|Reporter:||Morten Larsen (mlarsen)||Labels:|
|Date Opened:||2011-10-30 16:33:03||Date Closed:||2011-11-02 04:31:44|
|Versions:||220.127.116.11 18.104.22.168 22.214.171.124 10.0.0-beta2||Frequency of|
|Environment:||CentOS6, 4 GB RAM, Intel(R) Xeon(R) CPU E31220 @ 3.10GHz||Attachments:|
|Description:||Asterisk performs very poorly when the managerinterface is enabled.|
When enabled=yes in manager.conf the server starts to have periodic RTP dropouts on only 15 active calls. And if new calls arrive in a rate higher than 0.5 call/sec all SIP peers become unreachable as well.
Every time there is a dropout this message shows up in the cli/log: "utils.c: fwrite() returned error: Connection reset by peer" - That is despite no manager client has connected. Setting enabled=off in manager.conf gives instant improvement.
When enabled=no in manager.conf the server has no dropouts with >800 active calls, additionally it can handle a call flood of 12 calls/sec (didnt test with higher rates).
|Comments:||By: Walter Doekes (wdoekes) 2011-10-31 09:09:31.751-0500|
Have you looked at what's going on on the manager port using tcpdump?
By: Leif Madsen (lmadsen) 2011-10-31 13:34:14.210-0500
Requesting additional feedback from reporter.
By: Morten Larsen (mlarsen) 2011-10-31 14:15:50.413-0500
There is no traffic on the manager TCP port when this is happening.
By: Leif Madsen (lmadsen) 2011-11-01 08:33:38.546-0500
I wonder if getting a backtrace and 'core show locks' while this is happening would be useful. I've never heard of anyone experiencing this problem, so this is a unique case. I would think if this were a common problem a lot more people would be screaming about it (maybe not?).
In any case, we'll need additional information here in order to make it easy to reproduce. If you could provide a minimal set of configuration files which causes this problem it would go a long way to move this issue forward. I suspect if a developer just takes a sample set of files and enabled the manager, they are not going to run into this issue.
By: Leif Madsen (lmadsen) 2011-11-01 08:33:51.299-0500
Thank you for your bug report. In order to move your issue forward, we require a backtrace from the core file produced after the crash. Also, be sure you have DONT_OPTIMIZE enabled in menuselect within the Compiler Flags section, then:
After enabling, reproduce the crash, and then execute the backtrace instructions. When complete, attach that file to this issue report.
By: Walter Doekes (wdoekes) 2011-11-01 08:41:58.321-0500
I think Leif is a little distracted, since you weren't reporting a crash.
However, you can still get a core dump when this is happening, by killing asterisk with kill -ABRT.
Alternately, you can get backtraces while asterisk is still running by attaching to the running process using gdb -p <PID>.
By: Morten Larsen (mlarsen) 2011-11-01 17:13:05.789-0500
It turns out that there were something on the manager port after all - I was tcpdumping on eth0 but an old manager client application was connecting on the loopback interface. After stopping the client there is no issues with dropouts.
The client would connect and then send it's manager commands and disconnect while asterisk was sending a lot of events to the client.
I've modified the old app to turn off events during login and properly tear down the connection to the manager interface before close() is called on the fd. This resolved the problem we were having.
By: Walter Doekes (wdoekes) 2011-11-02 04:31:44.914-0500
Thanks for finding the problem. I think we can close this one.