Re: [zones-discuss] Zones and defunct processes bypassing the LWP rctl
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 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/ /rctl 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. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones and defunct processes bypassing the LWP rctl
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 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/ /rctl 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. Jerry 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. Regards -- Gael Martinez ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] zoneadm install help message gives wrong man page info about brands
Using S10u4 with 127111-03 and the S8MA pkgs. I ran zoneadm install with invalid arguments and the help message that was printed seemed inaccurate. A brand(4) man-page was mentioned, but I think it should be brands(5) which is mentioned in the man page of zoneadm. [EMAIL PROTECTED] zoneadm install solaris8 -u -a /mnt/cvstest.flar usage: install [brand-specific args] Install the configuration on to the system. All arguments are passed to the brand installation function; see brand(4) for more information. This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones and defunct processes bypassing the LWP rctl
Gael wrote: 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 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/ /rctl 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. Jerry 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: http://www.opensolaris.org/jive/thread.jspa?threadID=41108tstart=60 Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone.max-processes
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
[zones-discuss] RFC on introducing getzoneidbyname(9f)....
Looking in usr/src/uts/common/os/zone.c, there are is a number of functions that have the words Public interface before them, such as: /* * Public function to retrieve the zone status. The zone status may * change after it is retrieved. */ zone_status_t zone_status_get(zone_t *zone) ... However doing a man zone_status_get returns nothing, so it would appear that it isn't completely public. In light of there being a relative lack of public functions in the kernel to deal with zone names and id's, I'd like to propose providing an implementation of getzoneidbyname() and getzonenamebyid() for the kernel that mirrors the behaviour of those found in libc today. So to summarise, I'd like to provide getzoneidbyname(9f) and getzonenamebyid(9f) that have the same interface as getzoneidbyname(3c) and getzonenamebyid(3c). Comments? Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
