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.
I have seen prstat report that oracle workloads on a 15k domain are
using well over a terabyte of memory. This is kinda hard to do on a
domain with ~300 GB of RAM < 50 GB swap.
What is the best method to tie a certian
percentage of memory to certain zones — rcapd ??
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.
If the workload that you are trying to control is java-based, consider
using the various java flags to limit heap size. This will not
protect you against memory leaks in the JVM, but it will protect
against a misbehaving app. The same is likely true for the stack
size.
If the workload you are trying to control is some other single
process, consider using ulimit to limit the stack and heap size.
Set the size= option for all tmpfs file systems.
Bug the folks that are working on memory sets and swap sets to get
this code out sooner than later.
If running on sun4v, consider LDOM's when they are available (November?).
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
