On Aug 24, 2006, at 6:00 AM, Philip M. Gollucci wrote:

>> b- freebsd is showing a larger resident than size

> One is in KB the other is in Bytes -- thats due to the way getrusage
> (3) reports it.


under GTop.pm though? i'm not using bsd::resource. the libgtop
source suggests that its making use of getrusage, but i really don't
think its formatting one number different ( top and bsd::resource mix
units all the time. Gtop.pm doesn't seem to at all though )

GTop.pm is saying:
->size 46534656
->resident 52944896

ps is saying
root 93830 15.8 5.1 54928 51616

It looks to me more like GTOP is just wrong on that.



> I'm almost sure the Copy-on-Write reporting or Shared reporting is
> not correct (see below)
> Just because the reporting is wrong, doesn't mean that its not
> actually being shared.

i agree. i just want to be able to figure out what the hell is being
shared

> I think your best bet for that is to figure out how many children
> you need to spawn until just
> before you exhaust your physical ram. Then figure out how much of
> must be shared for it to not be swapping.

i was scared you'd say that.

> Since your parent started at 54928Kb no more then that can ever be
> shared unless you restart/change stuff.

that i knew.

> Seems that on startup 54984Kb is given to a child which is a delta
> of 56bytes that are not shared at startup.
> Thats actually better then most.

that took 3 days of profiling code.

> After 1 request, your child is at 55200Kb which means you allocated
> (55220Kb - 54984Kb) 216bytes
> None of which can ever be shared; however, when the child is reaped
> -- by A::SL or similar
> it should respawn at 54984Kb

that i expected, and it does work like that.


> Based on GTOP metrics above, you need to test the copy-on-write of
> FreeBSD..
> The A::SL docs have a method to do this contributed by Torsten
> Forsch(sorry if I spelled your name wrong)

i'm gonna try that right now. thats what is killing me.


> P.S. I've got to look up how GTOP from CPAN is interfacing with
> libtop2?.so and then how it interfaces with getrusage(3)


i actually tried to do it earlier. its damn confusing to me. i
couldn't find anything in libgtop2 that was directly calling
getrusage, outisde of some tests. so i'd brush up on the gterusage
internals before taking a stab at it.

> One can see the kernel lies about the shared memory. It simply doesn't
> count copy-on-write pages as shared.

i'm fine with it lying. i just don't like it lying differently on
every os.