> On 11/9/07, Jerry Jelinek <[EMAIL PROTECTED]> wrote:
>> Gael wrote:
>>> 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
>>> (no comments) generated so many processes that the whole frame was
>>> generating a lot of cannot fork errors... impacting the other zones and
>>> GZ ... The LWPs are limited to 500 in that zone (frame is a E2900 with
>>> 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
>>> allow some kind of limiting processes thru the GZ (the application
>>> 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.
> I'm using FSS as much as possible and positively in that one case, pools are
> only used when we need to mask the real amount of cpus to applications
> using commands like psrinfo or else to determine how many cpus are present
> in the system.
Since you are using FSS it sounds like you might be hitting the issue
discussed on the following thread:
zones-discuss mailing list