I would not be surprised to find that rcapd is behaving correctly on
your system. All of the containers in one Solaris instance share one
Solaris paging system and one set of swap devices. When rcapd is
paging the memory pages of one container out to the swap device, other
workloads sharing that disk will take longer to write to that disk.
This is similar to other virtualized solutions (e.g. hypervisors) that
have similar constraints, similar workloads and are sharing one
internal disk for swap space.
If your other containers are not paging at all, you can reduce this
effect by configuring your swap space on its own disk drive. The
"disk-write" transactions from those other containers will then *not*
wait for paging activity of the container with a RAM cap that is too
Do you know why that one container is using up more memory than the
cap? Is the cap too low, or the application behaving badly?
On Mon, Sep 1, 2008 at 7:55 AM, syed <[EMAIL PROTECTED]> wrote:
> Hi ,
> I am facing an issue with rcapd, currently I have setup 8 sparse-root
> containers on a server with 32G physical memory , I have capped each of
> these containers varyingly and there is no issue with capping and it works
> The issue arises when one of the containers eats up more memory (rapidly)
> than it has been allocated .It causes other non global zones to be less
> (noticable ) responsive while rcapd is trying to curb this unruly behaviour
> by one of the containers.I am wondering if this is due to heavy paging ?
> Has anyone else seen such behaviour, or is this an acceptable behaviour ? Any
> comments or experiences would be really helpful .
zones-discuss mailing list