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