Mike Gerdts wrote:
On 8/11/06, Irma Garcia <[EMAIL PROTECTED]> wrote:
ZONEID NPROC SIZE RSS MEMORY TIME CPU ZONE
15 188 169G 163G 100% 0:46:00 48% fmtest
0 54 708M 175M 0.1% 2:23:40 0.1% global
12 27 112M 51M 0.0% 0:02:48 0.0% fmprod
4 27 281M 66M 0.0% 0:14:13 0.0% fmstage
Questions?
Does the 100% memory usage on each mean that the fmtest zone is using all the
memory. How
come when I run the top command I see different result for memory usage.
The %mem column is the sum of the %mem that each process uses.
Unfortuantely, that value seems to include the pages that are shared
between many processes (e.g. database files, libc, etc.) without
dividing by the number of processes that have that memory mapped. In
other words, if you have 50 database processes that have used mmap()
on the same 1 GB database, prstat will think that 50 GB of RAM is used
when only 1 GB is really used.
Good observation, Mike. FYI, this is bug 4754856 (
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4754856 )
Irma, are the apps in fmtest using alot of shared memory?
I *think* that rcapd suffers from the same problem that prstat does
and may cause undesirable behavior. Because of the way that it works,
I fully expect that if rcapd begins to force pages out, the paging
activity for the piggy workload will cause severe performance
degredation for everything on the machine. My personal opinion (not
backed by extensive testing) is that rcapd is more likely to do more
harm than good.
It is plausible, though not always practical, to measure the amount of shared
pages for a particular zone during normal use, and factor that into the limits you
specify to rcapd.
It *is* easier to use rcapd safely with applications that do not use much shared
memory.
Bug the folks that are working on memory sets and swap sets to get
this code out sooner than later.
We are working very hard on those two feature sets. We have made a great deal of
progress, especially on memory sets, which is the higher priority of the two.
However, memory sets turned out to be more challenging than first expected.
If running on sun4v, consider LDOM's when they are available (November?).
LDOM's will avoid the problems described above, at the cost of some flexibility in
resource efficiency - the same cost paid by all consolidation solutions that use
muliple OS instances. For example, less RAM is used by sparse-root zones because
multiple instances of a program (e.g. /bin/ls) share common memory pages. LDOMs
(and other multi-OS-instance solutions) cannot do that.
--------------------------------------------------------------------------
Jeff VICTOR Sun Microsystems jeff.victor @ sun.com
OS Ambassador Sr. Technical Specialist
Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/zones/faq
--------------------------------------------------------------------------
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
