Hi Ben - The difficulty in getting accurate memory accounting has to do with shared memory pages. Every process that has a shared page mapped to its address space gets charged (in terms of RSS measurements).
I tend to use kstats (kstat -n system_pages) to get an idea of how much the kernel is using (kstat -p unix:0:system_pages:pp_kernel) and free page counts (kstat -p unix:0:system_pages:pagesfree). mdb's memstat is cool in how it summarizes things, but it takes a very long time to run on large systems. memstat is walking page lists, so it should be quite accurate. If you can live with the run time of ::memstat, it's currently your best bet for memory accounting. The kstats are useful for tracking the big picture, but they lack decomposing down to file system cache usage. You can get around that with ZFS arcstats. Process/thread memory usage accounting is skewed by shared pages. Fortunately, at the process level, most of the RAM used is for heap segments, which are easy to measure with a script around pmap(1) (unless you're running Oracle, which has a text segment larger than Rhode Island). I've often struggled with this. Memory observabilty is kind of a gap in Solaris today. DTrace is great for tracking active memory allocations and frees, but often all you want is a memstat-like snapshot. kstats get you close to that, but lack the granularity of memstat. I've often kicked around writing showmem(1) - something at the command level that covers memory usage, and includes the ever-confusing swap/VM stuff. I haven't done it because, on the other side of this coin, memory problems are so rare these days. HTH, /jim Ben Rockwood wrote:
I'm curious as to why memory statistics seems to be very difficult to be accurate about. If you use kstats, mdb ::memstat, and add up VSZ/RSS from ps, you get numbers that are different, although close. Can anyone shed some light on why this is? I'm assumed that ::memstat is the most accurate measure and I'm comparing my numbers against it, but perhaps it is not the best validation? benr. _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
_______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
