Jim Mauro wrote: > 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.
Very helpful, thank you. I agree that memory observability is somewhat lacking. The pmap idea is a good one except that the runtime on a system with a large number of processes would be excessive. It appears that I'll need to simply have to accept round numbers; trading execution time for accuracy. Knowing that ::memstat is accurate is extremely helpful, I at least can use that as a guide in developing non-mdb solutions. benr. _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
