Glad it worked. :-) The Tcl threaded allocator, which is derived from the original AOLserver "zippy" allocator, is optimized solely for lock avoidance, and this comes at the cost of memory foot print. In fact, there's no garbage collection for smaller allocations. Instead, memory moves between the shared and per-thread pools.
There are a couple of additional things you could try which may also help. Make sure you configure your connection threads such that they eventually exit. I believe by default they stick around forever and get re-used. This can be a good thing, but depending on the max number of connection threads you have configured, you may tying up a bunch of memory in the per-thread pool. When connection threads exit, the memory from the per-thread pool is returned to the shared pool. Another technique which has worked well is to move memory intensive tasks into the nsproxy. The nsproxy is a single-threaded tclsh which uses system malloc() and free(), and which will also return memory to the system on exit. We played around with various options in the new "zippy2" allocator, but never saw any major improvements, at least for the types of systems we ran at AOL. If you have time, you may want to try out Google's tcmalloc, as its being getting a lot of positive feedback, and is supposed to be optimized for threaded applications. On 12/11/06, Agnieszka Kukałowicz <[EMAIL PROTECTED]> wrote:
Hi, > Try the following as a replacement for the current Makefile: > > CLEAN = clean-it > INSTALL = install-it > LIB = zippy2 > LIBOBJS = tclThreadAlloc.o > CFLAGS += -I$(TCL)/generic > ... It works. Thanks a lot. > Also curious as to what motivated you to look into this in the first > place. Are you experiencing memory issues? Are you experiencing memory > issues? Yes, My production server uses a lot of memory (almost 2GB after one day running). First, I thought it was because of some kind of bad code in our application. But I made a lot of tests and statistics and I did notice nothing. The application is very stable, there is no leak of memory. My conclusion was it was due to memory alloction in AOLserver and articles in the Internet confirmed that. Now I'm testing AOLserver with Hoard and I need to say it looks very nice. The memory usage decreased about 20% - 40% depending on server parameters. I would also like to see how zippy2 works and compare it with hoard. I will let you know about results of my experiment. Cheers, Agnieszka -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to < [EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
-- Nathan Folkman [EMAIL PROTECTED]
