| Summary: | ASTERISK-16855: [patch] Loading chan_iax2.so allocates >100M RSS | ||||
| Reporter: | Jonas Bofjäll (job) | Labels: | |||
| Date Opened: | 2010-10-22 16:07:27 | Date Closed: | 2011-03-31 15:07:10 | ||
| Priority: | Minor | Regression? | No | ||
| Status: | Closed/Complete | Components: | Channels/chan_iax2 | ||
| Versions: | Frequency of Occurrence | ||||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) 20110124__issue18194.diff.txt | |||
| Description: | The main asterisk process resident memory usage jumps over 100 MB when loading chan_iax2.so. The configuration file iax.conf is empty. If this is not reproducible for other people, let's compare build environment and libraries. | ||||
| Comments: | By: Tilghman Lesher (tilghman) 2010-10-23 14:58:52 I understand the statement of fact. However, I don't see that there's a problem with chan_iax2 allocating 100MB of memory. It's allocating memory in advance, for better performance. By: Jonas Bofjäll (job) 2010-10-23 16:48:51 I very much doubt this is by design. It is 10x the amount of all the other channel drivers added together. No earlier version of chan_iax2 did this. By: Jean-Denis Girard (jdg) 2010-10-26 21:12:53 Same here. This is a problem for embedded systems, though building with LOW_MEMORY compiler flag returns to normal memory usage. By: Jeremy B (captainjez) 2010-12-01 13:54:01.000-0600 I'm also seeing this with 1.8.0 on FreeBSD 8.1 with a blank iax.conf. By: Jeremy B (captainjez) 2010-12-04 15:39:42.000-0600 Any updates on this? I'm happy to provide more information. By: Jeremy B (captainjez) 2010-12-30 22:02:56.000-0600 This is still happening with 1.8.2 rc1. By: Tilghman Lesher (tilghman) 2010-12-31 03:38:41.000-0600 If this is that big of a deal to you, perhaps you should be doing more investigation as to the cause and possible fix. Right now, given that it does not lead to an actual failure condition, it is relegated to rather low on the priority scale. Unless you do the work yourself, it is unlikely this issue will advance to a fix anytime soon. By: Jeremy B (captainjez) 2011-01-16 20:41:58.000-0600 I've tried this patch on 1.8.1.1, but the last part of the patching fails: -------------------------- |Index: main/lock.c |=================================================================== |--- main/lock.c (revision 300043) |+++ main/lock.c (working copy) -------------------------- Patching file main/lock.c using Plan A... Hunk #1 failed at 0. 1 out of 1 hunks failed--saving rejects to main/lock.c.rej done I'm keen to get this working. By: Jeremy B (captainjez) 2011-01-23 23:16:53.000-0600 The patch fails on SVN and tarballs. It looks like the patch is trying to remove the entire contents of lock.c. By: Tilghman Lesher (tilghman) 2011-01-24 00:09:30.000-0600 That is correct. The patch reverts the change which created that file. By: Jeremy B (captainjez) 2011-01-24 02:28:25.000-0600 Is lock.c meant to be empty or non existent? When I manually apply the patch I get build errors. By: Jeremy B (captainjez) 2011-01-24 03:25:35.000-0600 I can confirm removing lock.c and building Asterisk 1.8.2.2 I no longer have the excessive memory usage. My install is now sitting at ~ 19MB on FreeBSD 8.1. So far so good. I'll continue to test. Thanks again for the fix. By: Tilghman Lesher (tilghman) 2011-01-24 04:33:10.000-0600 Alternate fix in a branch here: http://svn.asterisk.org/svn/asterisk/team/tilghman/issue18194 By: Digium Subversion (svnbot) 2011-01-31 00:41:39.000-0600 Repository: asterisk Revision: 304950 U branches/1.8/.cleancount U branches/1.8/include/asterisk/lock.h U branches/1.8/main/heap.c U branches/1.8/main/lock.c U branches/1.8/main/utils.c ------------------------------------------------------------------------ r304950 | tilghman | 2011-01-31 00:41:38 -0600 (Mon, 31 Jan 2011) | 18 lines Change mutex tracking so that it only consumes memory in the core mutex object when it's actually being used. This reduces the overall size of a mutex which was 3016 bytes before this back down to 216 bytes (this is on 64-bit Linux with a glibc-implemented mutex). The exactness of the numbers here may vary slightly based upon how mutexes are implemented on a platform, but the long and short of it is that prior to this commit, chan_iax2 held down 98MB of memory on a 64-bit system for nothing more than a table of 32767 locks. After this commit, the same table occupies a mere 7MB of memory. (closes issue ASTERISK-16855) Reported by: job Patches: 20110124__issue18194.diff.txt uploaded by tilghman (license 14) Tested by: tilghman Review: https://reviewboard.asterisk.org/r/1066 ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=304950 By: Digium Subversion (svnbot) 2011-01-31 00:50:50.000-0600 Repository: asterisk Revision: 304951 _U trunk/ U trunk/.cleancount U trunk/include/asterisk/lock.h U trunk/main/heap.c U trunk/main/lock.c U trunk/main/utils.c ------------------------------------------------------------------------ r304951 | tilghman | 2011-01-31 00:50:49 -0600 (Mon, 31 Jan 2011) | 25 lines Merged revisions 304950 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r304950 | tilghman | 2011-01-31 00:41:36 -0600 (Mon, 31 Jan 2011) | 18 lines Change mutex tracking so that it only consumes memory in the core mutex object when it's actually being used. This reduces the overall size of a mutex which was 3016 bytes before this back down to 216 bytes (this is on 64-bit Linux with a glibc-implemented mutex). The exactness of the numbers here may vary slightly based upon how mutexes are implemented on a platform, but the long and short of it is that prior to this commit, chan_iax2 held down 98MB of memory on a 64-bit system for nothing more than a table of 32767 locks. After this commit, the same table occupies a mere 7MB of memory. (closes issue ASTERISK-16855) Reported by: job Patches: 20110124__issue18194.diff.txt uploaded by tilghman (license 14) Tested by: tilghman Review: https://reviewboard.asterisk.org/r/1066 ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=304951 | ||||