FYI Memory Requirements for Asterisk 1.4, 1.6, 1.8

[jeffmac]

I'm curious of other folks are seeing the same kind of memory requirements I'm seeing.

I run my "production" home PBX on a PIAF "gold", so its a 1.4.21.2 system. According to "top", Asterisk has a virtual size of 35MB and 12MB "resident". (This is a an Atom dual-core 2GB box).

I have a small "special purpose" system (for traveling) running on a Seagate dockstar with 128MB of memory. Its NOT PIAF but a self-compiled Asterisk 1.6 with FreePBX. (Not all the features of PIAF but similar to a VPN-in-a-Flash using openVPN). "top" there shows Asterisk with a virtual size of 41MB and resident size of 10MB.

Now I've installed PIAF "purple" a couple of times on a spare box ( its a VIA c7-D with 1GB) and of course its Asterisk 1.8 - but the memory requirements are STAGGERING! According to "top" Asterisk has a virtual size of 155MB and 126MB resident!

I'd like to consider a 1.8 for my portable unit but the swapping would simply be unbearable, or it would simply panic very frequently.

I haven't seen much "wailing and gnashing of teeth" over this in any of the forums, although there have been some reports of memory leaks. But I just booted that "purple" system last night (15 hours ago) so if its a leak its really a bad one. And this new build has one ATA active and the Google Voice definitions - not much demand.

I know 2GB is cheap these days, but has anyone else noticed this? I remember running my first Asterisk at Home on a 256MB Pentium II.

Jeff

 

[dswartz]

Hmmm, my bronze shows 42M and 14M.

 

[malcolmd]

What about if you disable the loading of the chan_iax2.so module? Does that change the memory footprint appreciably?

 

[jeffmac]

WOW! Does it ever!

After restart with noload=chan_iax2.so the virtual size is 51MB and resident is 26MB.

Is there something radically different or radically wrong with IAX2 in 1.8? I might actually want to use it, as that's how my "portable" system connects once the VPN is established.

Jeff

 

[malcolmd]

We've got a discussion going on about this in this (http://lists.digium.com/pipermail/asterisk-dev/2011-January/047475.html) thread on the developers mailing list.

Cheers.

 

[blanchae]

Here's the Asterisk bug report 0018194, unfortunately, it's considered a low priority issue - read the "manager's" response - (mental note: don't ever respond on New Year's Eve).

 

[malcolmd]

Reviewboard (https://reviewboard.asterisk.org/r/1066/) indicates that further discussion is necessary.

As to priorities, crashes and bugs (features that don't operate correctly) are almost always going to rate ahead of memory consumption issues, unless they're runaway/race conditions. So, it'll end up on the list, but it won't be at the top - and I think that's fair.

Cheers.

 

[dswartz]

Working in a software maintenance org, I'm not sure I would classify a memory consumption issue like this as not being a bug. Our customers certainly wouldn't Especially if they start getting OOM failures...

 

[malcolmd]

OoM if it turns out to be some kind of race condition that results from a leak is bad, really bad.

But, overly large consumption that only impacts your free memory, and given the general usages of Asterisk, seems to be further down the totem pole of importance than many other issues. We're in the position of having more issues to solve than time to solve them, thus prioritization.

We try to do what's best, always.

 

[dswartz]

True enough - I'm well aware of the no-win aspect of prioritizing bugs