Forum OpenACS Q&A: Re: Upload large files on Aolserver - Is moving to Naviserver the only way?
The Tcl implementation favors speed over space consumption and over-allocates memory eagerly (essentially doubling the allocated size of a string allocation when it needs more space). With bad luck, if you have a string of 1MB and you append one byte, then it allocates 2MB. This works in practice much better as it sounds. However, if this string is truncated later to e.g. 10bytes, these 10 bytes are still sitting in the 2MB allocation.... in such cases, a different malloc won't help at all. The bad things of the zippy malloc are (1) that it never releases memory and (2) that it leads to a large vsize (where people often argue that this does not matter), while the good thing is that it uses very little mutex locks. Check [1] for some results of using tcl with different memory allocators.
If you are concerned about memory consumption, NaviServer is as well on longer running server the better choice, since it has less memory leaks and it is less exposed to stress reactions causing eager thread creations. This can be seen partly by the following chart showing the memory size of the aolserver/NaviServer running openacs.org:
From Aug to June one sees the memory consumption of the aolserver with reboots in Nov and Dec. In July we first upgraded pg 8.3 to 8.4, which brought the machine nearly to a halt due to the slow permission queries, leading to the mentioned stress reactions. After upgrading to pg 9 + NaviServer, one sees essentially a flat line of memory consumption (with the zippy allocator) using a total of currently 27 threads (including writer threads etc.) The aolserver variant used typically 17 threads, but used more memory. One can certainly further reduce the long range memory consumption by using other mallocs, but this is currently not a concern.
[1] https://next-scripting.org/xowiki/docs/misc/thread-mallocs/index1
