In a message dated 10/29/04 10:23:42 AM, [EMAIL PROTECTED] writes:
Still, this doesn't help answer the question of "why is Andrew's nsd at
1.3 GB and growing" -- especially when the same exact app. under
AOLserver 3 remains stable while on AOLserver 4 it seems to
continuously grow ...
We should always see a larger process size then the sum of the memory being tracked via the Tcl threaded allocator (which was the old "zippy" aolserver allocator). Reasons include:
- sizes of mapped files, libraries, cached files, etc.
- underlying malloc overhead -- headers and fragmentation
It's possible the Tcl threaded allocator is not well matched to the underlying malloc, i.e., requests to allocate 16k blocks and chunk them up into the various bucket size may actually allocate much more depending on the malloc.
Things to try:
- consider fixing what could be a bug in the Tcl thread allocator (generic/tclThreadAlloc.c) -- seems like MAXALLOC and the last buketInfo slot should be 16384, not 16284, which may be causing some waste for these block sizes.
- try disabling zippy by re-compiling Tcl without enabling the thread allocator. This should be ok unless you have a very busy site.
- try getting stats from underlying malloc and/or swapping out another malloc (Hoard, various debug options, etc.)
- try hacking the Tcl allocator to use mmap directly to get the 16k chunks, bypassing malloc directly. Use caution here to avoid too many mapped regions (i.e., pass out 16k chunks from larger mmap'ed regions, e.g., 16megs or so).
Of course ever-growing servers that don't eventually stabilize indicate memory leaks, not fragmentation or other overhead.
-Jim
2">
