Hi Mike,

> processes are counted multiple times.  In an extreme example of a busy
> 15k domain with hundreds of gigabytes of physical RAM and less than 50
> GB swap, "prstat -a" will report that many terabytes of memory are in
> the resident set for the oracle user.  This is impossible.

About the only thing prstat could do today about this is to read
/proc/pic/map files and go through all memory segments for each
process looking for processes using the same pr_shmid (see proc(4)).
That will slow down prstat and yet won't not be 100% accurate as
there are other types of shared memory (shared libc text, for example).

Changing the VM subsystem to do better accounting for shared
memory for projects was considered but never happened... again
because of serious concerns about the impact that this change
would have on performance.  One suggested alternative was to at
least keep accurate (as in pmap -x) per-segment RSS counts at
all times.  That didn't happen either since we didn't have resources
at the time for this and there were more importants problems
to solve.

The other problem with RSS which gets reported by /proc/pid/psinfo is
that it's not very precise.  It's an estimate, really.  Check out
rm_asrss() routine in vm_rm.c:
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/vm/vm_rm.c

So, unfortunately, the current situation with memory accounting
is not perfect *and* there's very little room for improvements.

The good news is that  Memory Sets and Swap Sets projects
will solve two other problems you've identified :-)

- Andrei
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org

Reply via email to