Andrew Grumet <[EMAIL PROTECTED]> wrote:
> Okay I took another measurement. This time the footprint was 1358MB.
> This page has near-simultaneous output of ns_info pools and ns_info
> threads.
>
> http://grumet.net/scratch/pools2
OK, here's the output from my script:
THR ID BYTES NAME, PARENT, PROC
24 1061842636 -driver- -main- | p:ff323c80 a:0x0
27 62454988 -sched:idle1- -sched- | p:ff33c6e4 a:1
26 62209081 -sched:idle0- -sched- | p:ff33c6e4 a:0x0
30 59578568 -sched:idle4- -sched- | p:ff33c6e4 a:4
29 59527285 -sched:idle3- -sched- | p:ff33c6e4 a:3
1 51130900 -main- {} | p:0x0 a:0x0
shared 26706412 shared
28 21432088 -sched:idle2- -sched- | p:ff33c6e4 a:2
3 10250711 -sched- -main- | p:ff33ca64 a:0x0
10 -25609229 -conn:ssv2::6 -main- | ns:connthread {}
23 -27794744 -conn:ssv2::19 -main- | ns:connthread {}
9 -28575328 -conn:ssv2::5 -main- | ns:connthread {}
5 -29617870 -conn:ssv2::2 -main- | ns:connthread {}
13 -29919773 -conn:ssv2::9 -main- | ns:connthread {}
19 -31431446 -conn:ssv2::15 -main- | ns:connthread {113717 146.115.120.81
running GET /mem 0.33716 0}
18 -31506322 -conn:ssv2::14 -main- | ns:connthread {}
20 -31818524 -conn:ssv2::16 -main- | ns:connthread {}
8 -32097598 -conn:ssv2::4 -main- | ns:connthread {}
21 -32244499 -conn:ssv2::17 -main- | ns:connthread {}
16 -32439429 -conn:ssv2::12 -main- | ns:connthread {}
17 -32464142 -conn:ssv2::13 -main- | ns:connthread {}
6 -32500413 -conn:ssv2::1 -main- | ns:connthread {}
7 -34144661 -conn:ssv2::3 -main- | ns:connthread {}
15 -34227120 -conn:ssv2::11 -main- | ns:connthread {}
14 -34457112 -conn:ssv2::10 -main- | ns:connthread {}
12 -34498309 -conn:ssv2::8 -main- | ns:connthread {}
4 -35326644 -conn:ssv2::0 -main- | ns:connthread {}
22 -36337468 -conn:ssv2::18 -main- | ns:connthread {}
11 -36517544 -conn:ssv2::7 -main- | ns:connthread {}
The sum on the BYTES column gives 771,604,494 which bothers me that it's
so far off from 1.3 GB - nearly half.
Talking to Jim yesterday, he explained why it's possible for a thread to
have more puts than gets: one thread allocates memory (gets) and another
thread frees it (puts).
The sum of all the conn threads above is -643,528,175 -- if we assume
that memory is being allocated in the driver thread and freed in the
conn threads after the conn's done, then the driver thread's memory is
really closer to 418,314,461 ...
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 ...
Perhaps it's time to take another run through with Purify/valgrind and
look for lost memory. Also, consider how you're using NSV's and
nscache, etc.
-- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--
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.
