Summary: | ASTERISK-10958: asterisk permanently burden cpu | ||
Reporter: | pj (pj) | Labels: | |
Date Opened: | 2007-12-03 13:34:01.000-0600 | Date Closed: | 2007-12-12 17:41:26.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | even if no call processing and about four registered idle peers, asterisk causes about 15% cpu load on PII@300MHz, previous svn trunk (about two weeks ago) was OK (0% cpu when idle). ****** ADDITIONAL INFORMATION ****** PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1614 asterisk -11 0 17984 8120 4144 S 14.3 6.4 8:58.43 asterisk | ||
Comments: | By: pj (pj) 2007-12-05 12:32:34.000-0600 any way how to debug cpu load issue with latest rev. of asterisk trunk? last revision, that I tested and not produce excessive cpu load is Asterisk SVN-trunk-r89551 By: pj (pj) 2007-12-05 12:50:48.000-0600 overall performance is also significantly degraded with latest asterisk trunk, one trancoding alaw-gsm session consumes about 50% cpu! By: pj (pj) 2007-12-10 13:31:29.000-0600 interval for bug finding narrowed: Asterisk SVN-trunk-r89721 (and below) OK Asterisk SVN-trunk-r89982 (and above) BAD By: pj (pj) 2007-12-12 13:31:17.000-0600 I finally found source of this issue, it's Russell's commit to trunk r89887 (optimization for chan_iax2). Asterisk SVN-trunk-r89847 OK Asterisk SVN-trunk-r89887 BAD By: Digium Subversion (svnbot) 2007-12-12 17:41:26.000-0600 Repository: asterisk Revision: 92676 U trunk/channels/chan_iax2.c ------------------------------------------------------------------------ r92676 | russell | 2007-12-12 17:41:25 -0600 (Wed, 12 Dec 2007) | 7 lines Revert an "optimization" that I added in revision 89887, as the user who reported issue ASTERISK-10958 has demonstrated that it actually was a performance hit on his machine. I think that it is possible that it could still be a benefit on systems under higher load, especially SMP systems, but I don't have enough time or interest to find out at the moment. (closes issue ASTERISK-10958) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=92676 |