[EMAIL PROTECTED] wrote:
http://grumet.net/scratch/pretty-pools
Thanks, Nathan! I think somewhere in the gig range we start to run into the Tcl max integer, which might cause the arithmetic to fail. Anyway, does this readout speak to you?
Also, I'm adding tallies at the bottom of
http://grumet.net/scratch/pools
where I divide out by 1024 and 1024*1024 to keep the numbers from getting too big.
-- 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.
Yeah, there are a bunch of issues that need to be addressed in that stats display code...
From what I saw, it looks about right. Generally you should see numbers that look like this:
Total bytes requested: 424989217 Total bytes free: 55156136 Total bytes allocated: 738315272 Total bytes wasted: 313326055 Total byte overhead: 73.73% Total mutex locks: 4792223 Total mutex lock waits: 0 Lock wait ratio: 0.00% Total get/puts: 827877527 Lock avoidance: 99.42%
The important numbers to look at are the "lock avoidance" and "total byte overhead". The big win with the "zippy" memory allocator is that it reduces lock contention to just about zero. Unfortunately this comes at the cost of higher allocations, which you can see by looking at the difference between "bytes requested" vs. "bytes allocated".
Anyhow, not really sure what you are trying to figure out, but hopefully this information helps! ;-)
-- 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.
