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
Priority:	Critical	Regression?
Status:	Closed/Complete	Components:	Core/ManagerInterface
Versions:	1.8.5.0 1.8.7.0 1.8.7.1 10.0.0-beta2	Frequency of Occurrence
Related Issues:
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[1] from the core file produced after the crash. Also, be sure you have DONT_OPTIMIZE enabled in menuselect within the Compiler Flags section, then: make install After enabling, reproduce the crash, and then execute the backtrace[1] instructions. When complete, attach that file to this issue report. [1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace 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.