Re: [zones-discuss] zone.max-processes

[Menno Lageman]

Steve Lawrence wrote:
 
 We have a generic rctl/global-zone safety issue that needs to be addressed.
 It would seem simple enough to just make project 0 processes in the global
 zone exempt from zone rctls.  This would allow apps in the global zone to
 be capped without affecting system daemons.
 
 The rational is that system daemons need resources or the system can become
 unusable.
 
 The hole in this solution is that, by default, root logins join the user.root
 project.  A fix could be to make root's default project system instead of
 user.root.  This would be a significant change.  Another option would be to
 document that admin's change root's default project to system if configuring
 rctls on the global zone.  We could even print a warning if configuring via
 zonecfg -z global.
 
 Comments?

Steve,

making only the system project exempt from the zone rctl to ensure 
proper system operation seems reasonable to me. I am not sure about the 
'make the system project root's default project' bit. We don't do that 
for zone.max-lwps, do we?

Setting zone.max-lwps too low in the global zone will render the system 
as unusable as when setting zone.max-processes too low, yet we don't 
cater specifically for the well being of the system in the zone.max-lwps 
case, so why do it for zone.max-processes? We threaten the admin with 
fire and brimstone when he/she sets max-lwps using zonecfg, but other 
than that, we do nothing else.

Given that the intended use of zone.max-processes is mainly for 
non-global zones, I think it is reasonable to expect that the majority 
of admins won't be setting zone.* rctls on the global zone. Preventing 
those that want to from doing so by making the global zone exempt from 
the zone rctl seems overly protective. The current warning by 
zonecfg(1M) and a new stern warning in the zonecfg(1M) man page should 
suffice to make the admin aware of the dangers.

So the only thing exempt from project.max-processes and 
zone.max-processes would be processes in the system project in the 
global zone for the reason you stated. For non-global zones, the zone 
limit will be an unconditional limit (no exemption for anyone since the 
rctl is meant to protect the system and other non-global zones from a 
rogue zone).

Menno

--
Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno

___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] zone.max-processes

[Jason Schroeder]

Yes please.  This is a common request for the scenerios you describe and to me 
seems a logical addtion to the existing lwps control at a zone granularity.  
Applying the control on the global zone is interesting, but not as important as 
having the control per non-global zones.

/jason
 
 
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] zone.max-processes

[Flemming Danielsen]

Hi

I have found in the past that it is frustrating to find resources  
rctl that is not in sync between projects and zones definitions and  
as a costumer I would like to see them in sync.

It would also enable me to isolate applications in zones that tend to  
blow up the zone where I have other part of the workload running  
(other projects).

I would like you to consider something more appropriate then a  
unlimited value of processes in global zone. We did an experiment  
where we created about 400-500 zones and we to hit some limits in the  
default kernel when we reached 8 lwps. This will also affect the  
process limits.  I expect there is a kernel structure that needs to  
be tuned, but I have not had the need to build a 500 zones system  
yet :-) But since you put a lower limit you might investigate how o  
put in a upper limit (based on kernel structures)

On 03/10/2007, at 22.37, Menno Lageman wrote:

 Steve Lawrence wrote:
 Have you considered also implementing project.max-processes?  This  
 would
 give a zone admin some control over workloads within the zone.  I  
 would
 follow suit and make project 0 in the global zone exempt from its
 project.max-processes rctl.

 I hadn't considered project.max-processes yet, mainly because what  
 I see
 in the field is that most people seem to consider project rctls to be
 too much detail. Configuring limits at the zone level seems to be the
 preferred option. But it can't hurt to see what it would take to also
 have project.max-processes.

 Menno
 -- 
 Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno
 ___
 zones-discuss mailing list
 zones-discuss@opensolaris.org

___
zones-discuss mailing list
zones-discuss@opensolaris.org