Forum OpenACS Q&A: Run out of mempry with aolserver

Collapse
1: Run out of mempry with aolserver
Posted by Iuri Sampaio on 01/08/07 06:02 PM
How much memory aolserver is usage?
I've followed the tutorials, and info on oacs website about memory optmization. But i still face the "no memory screen".

I have a debian server with 128mb RAM memory, and only one service running at port 80. I am frequently running out of memory to install the packages or even to run a simple query separatedely

What is the best approach to this issue?

Collapse
2: Re: Run out of mempry with aolserver (response to 1)
Posted by Andrew Piskorski on 01/12/07 01:39 PM
Iuri, your box really only has 128 MB of RAM? Why? That's astonishingly tiny these days.

The best and simplest approach is to get a box with lots more RAM, 512 MB at the very least, preferably more. (Even a cheap 6 year old 1.3 GHz Pentium 4 is probably going to let you install 1.5 GB or so...)

I have no idea what a "no memory screen" is. How much swap space do you have configured? You probably need more, as normally if your AOLserver is using too much RAM, the symptom should be that it slows way down due to swapping, not that it dies.

When using OpenACS, AOLserver's connection threads are pretty "fat" - they take quite a bit of memory - so at least to start, set your minthreads and maxthreads as low as possible.

AOLserver's default ("zippy") multi-threaded memory allocator is optimized for low contention, and wastes memory to get it. In your case, try building Tcl and AOLserver to use the standard system malloc, not Tcl's threaded allocator. I think Tcl's "--enable-threads" configure option turns on both the thread support and the threaded allocator. You want the threads but not the allocator, so you'll probably have to do "--enable-threads" and then hack the generated Makefile to turn off the threaded allocator. Check the AOLserver email list archives, this was all discussed there fairly recently.

Reportedly, in recent versions of Linux the system malloc is much better for multi-threaded programs than it used to be, it's now nearly as fast as the Tcl threaded allocator, and uses much less memory.