Forum OpenACS Q&A: OpenACS memory footprint

Collapse
1: OpenACS memory footprint
Posted by Mark Aufflick on 08/25/05 07:22 PM
AOLserver 3.2+ad / OpenACS 4.6.3 => 60 MB process size
AOLServer 4.0.10 / OpenACS 5.2 (not .LRN) => 100 MB
AOLServer 4.0.10 / OpenACS 5.1 (.LRN) => 130 MB

I'm seeing this across a number of sites of similar complexity.

I wonder if the memory footprint is from Oacs doing more in tcl, or if AOLserver 4 has a substantially larger overhead.

I can drop each of them down by 15-25 Mb by reducing the stack size.

What settings do people use and what memory footprint do they see?

Collapse
2: Re: OpenACS memory footprint (response to 1)
Posted by Jun Yamog on 08/26/05 07:19 AM
I see similar level, sometimes on the 200mb level. I don't monitor the level too much since 200mb for me is pretty low.
Collapse
3: Re: OpenACS memory footprint (response to 1)
Posted by Gustaf Neumann on 08/26/05 04:08 PM
one can significantly reduce the memory footprint by using ttrace. ttrace does not produce the large "blueprint" of all (used and unused) tcl procs, but builds an index instead and the unknown mechanism of tcl to load tcl procs (and xotcl methods) on demand. according to zoran, it can reduce the memory footprint to a third and improve the thread startup time by a factor of 50.

there might be some fiddling around with introspection commands (e.g. info args procname won't work, when procname is not already loaded on demand; up to some degree, ttrace tries to handle such cases) and similar issues. i tried it some time ago with xotcl, where it worked nicely; we do not use it on our production site, where we see no memory problems. ttrace is part of libthread 2.6 or newer. for a pointer, see
https://openacs.org/forums/message-view?message%5fid=313348

Collapse
4: Re: OpenACS memory footprint (response to 1)
Posted by Andrew Grumet on 08/26/05 04:17 PM
My stacksize is set for [expr 128 * 8192], I think that's the default.

Memory footprint is currently 200mb but it also grows depending on traffic.

For a long time I've been suspicious that there's a memory leak somewhere in either OpenACS or AOLserver. After many iterations working on this with Dossy we still haven't found anything in AOLserver, but I haven't taken a good hard look at OpenACS in a while.

Collapse
5: Re: OpenACS memory footprint (response to 1)
Posted by Jeff Davis on 08/27/05 03:22 PM
The CVS version of ttrace works with openacs 5.2 (at least the parts I was
using - not .LRN though) and for the dev installs reduced the footprint
from about 200mb to 110mb. It broke some of the tcllib packages
which the soap stuff depended on, and when something breaks
because the package breaks because of ttrace it's pretty tricky to
track down.

The overhead for ttrace is pretty low (mostly startup although a few
operations are slower as well) and it's worth using I think but it can
break things in pretty non-intuitive ways.

One reason the memory footprint for aolserver climbs is that over time
it creates a lot of threads for sweepers as there seems to be no way
for those threads to ever expire (so you might end up with 10-15 threads
for handling scheduled procs).

Collapse
6: zombie sweeper threads? (response to 5)
Posted by Andrew Piskorski on 09/21/05 10:50 AM
Jeff, could you give more info please on this problem with scheduled proc sweeper threads you're talking about? It certainly doesn't seem right that any threads should ever be forced to hang around forever doing nothing. (Perhaps some threads are supposed to be created detached but are not, and are never exiting because no other thread is waiting on them?)