On Mon, Sep 1, 2008 at 6: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 fine. > > 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 ?
What does "vmstat -p" say? I bet it says "yes!" > Has anyone else seen such behaviour, or is this an acceptable > behaviour ? Any comments or experiences would be really helpful. I haven't, but then again that is because I expected to see such behavior if I used rcapd. There are very few circumstances in my world that make sense to encourage heavy paging - as rcapd will do. Solid state disk may change this a bit because paging would likely be a lot faster. For now, my approach is to cap the use of swap. Note that in this definition, "swap" is different than most people expect - it refers to how much memory a zone can reserve. If the sum of all of your zones' swap cap is 32 GB, you should see pretty much no paging to swap devices. You will still see file system (e.g. executable) paging. The most noticable side effect is that if the things running in a zone (including use of /tmp) try to use more than their respective caps, memory allocations will fail. I see this as a good thing because it means that the misbehaving application fails rather than taking down all the rest. rcapd works a bit like boot camp (military - not the mac thing). If one soldier (zone) misbehaves they all get punished. There may be circumstances where this outcome is desirable but server virtualization using zones is likely not one of them. -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
