Forum OpenACS Q&A: OpenACS memory footprint
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?
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
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.
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
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).