> I had the bad surprise to find a production zone impacting a whole frame
> this morning... visibly the third party application running in it as root
> (no comments) generated so many processes that the whole frame was
> generating a lot of cannot fork errors... impacting the other zones and the
> GZ ... The LWPs are limited to 500 in that zone (frame is a E2900 with 12
> cpus), but troubleshooting showed that the defunct process didn't get
> attached to LWPs and therefore didn't hit the wall ... Is there any plan to
> allow some kind of limiting processes thru the GZ (the application running
> as root, I do not know how to project it) ?
> <rctl name="zone.max-lwps">
> <rctl-value priv="privileged" limit="500" action="deny"/>
> This is a scaring issue ...
Do you have FSS configured as the default scheduling class on
the system? By itself the max-lwps rctl cannot control this
situation but when used in conjunction with FSS things should
be fine. Except for rare cases I would say that you should always
be using FSS when you are using zones and sharing all of the
system resources amongst the zones. If you are using pools
instead then that recommendation wouldn't apply.
zones-discuss mailing list