Whenever I have tried to take a look at who is using lots of memory on a system running non-trivial workloads, I have met with limited success largely due to the fact that pages in the RSS of multiple 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.
On Solaris 9 and earlier this wasn't a big deal. I would just look at the vmstat's data to be sure that bad things weren't happening to the system. Now I would like to be able to cap memory per zone. Because rcapd only seems to be able to set limits on all processes in a project, I am pretty much forced to put all of the non-system processes (those that use all the RAM, I hope) into a single project in each zone. However, perusing the rcapd source, it looks as though it too simply adds up the RSS without regard for things like shared memory segments or mmap'd files. As such, zones with many programs that make use of shared memory segments, large executables or libraries, or other large memory mapped files, will be unfairly targetted by rcapd. There are other problems that further limit the usefulness of setting memory caps per project in attempt to isolate the impact of piggy zones. The problems I see with the current model are: 1) Pages mapped in multiple processes' address spaces are counted multiple times. 2) If root is not well controlled in a zone (somewhat encouraged by marketing, it seems) the zone's root user can do away with the memory caps altogether. 3) There is no way to indicate that misbehaving programs in one zone cannot consume all of the system's swap or cause such heavy paging activity that other zones are significantly affected. 4) /tmp can be misused to use lots of RAM. This problem is worse if root in the zone is not well controlled (size=X mount option no longer reliable). Have I missed a more effective mechanism for limiting RAM (and swap) usage per zone? Alternatively, is there a more effective mechanism in the works to set zone-wide limits from the global zone? Mike _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org