Am 06.04.2005 um 20:49 schrieb Jim Davidson:
I don't believe zippy is technically leaking memory but it will lead to bloat as it's primary goal, in fact it's only goal, is lock contention avoidance. This means per-thread pools are spun up for all small allocations. When threads exit, they transfer remaining blocks to the "shared" pool. However, any tracking of original source of allocation is not maintained so there is no means to coalesce previous blocks and free large chunks which were originally chopped up for the various blocks sizes.
The example above is the sort that would lead to fragmentation, many short lived threads which lead to short-live per-thread pools. Things should eventually stabilize as the shared pool is filled with blocks from previous threads.
This is the startup on Mac OS X:
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 23278 nsd 0.0% 0:00.28 6 38 84 1.33M 2.78M 3.97M 42.3M
Then I run:
server1:nscp 2> time {set t [ns_thread begin "set a 1"]; ns_thread join
$t} 10000
34006 microseconds per iterationand afterwards it looks like this:
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 23278 nsd 0.0% 4:12.12 6 38 5103 357M 1004K 29.6M 539M
The virtual size went up 13 times. If I continue the stress-test it grows further, So, it seems it is not stopping at some point, i.e. it does not stabilize.
I have also tried with Tcl 8.4.5 - 8.4.9 but no improvements. All is done with stock server 4.0 server.
So, it seems to me that there is something wrong sitting there... Can it be that there is some cleanup-thing missing there?
Zoran
-- 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.
