Re: [zones-discuss] Zone in a pset with high load generating high packet loss at the frame level

2009-03-05 Thread Bob Netherton
1. Do you use set pool= anymore, now that the dedicated-cpu feature exists? Until Oracle develops a more rational licensing scheme you should expect this feature to be in use. I may have many Oracle instances, each in a separate zone, using the same pool. The sampling on this discussion

Re: [zones-discuss] Zone in a pset with high load generating high packet loss at the frame level

2009-03-05 Thread Gael
On Wed, Mar 4, 2009 at 9:06 AM, Jeff Victor jeff.j.vic...@gmail.com wrote: Some questions: 1. Do you use set pool= anymore, now that the dedicated-cpu feature exists? We got over one hundred physical frames running zones here, covering nearly all versions of Solaris 10, we are currently

Re: [zones-discuss] Zone in a pset with high load generating high packet loss at the frame level

2009-03-05 Thread Jeff Victor
Thanks for the great feedback Gael. Comments below. On Thu, Mar 5, 2009 at 11:00 AM, Gael gael.marti...@gmail.com wrote: On Wed, Mar 4, 2009 at 9:06 AM, Jeff Victor jeff.j.vic...@gmail.com wrote: Some questions: 1. Do you use set pool= anymore, now that the dedicated-cpu feature exists? We

Re: [zones-discuss] Zone in a pset with high load generating high packet loss at the frame level

2009-03-05 Thread Steve Lawrence
On Thu, Mar 05, 2009 at 01:22:25PM -0500, Jeff Victor wrote: Thanks for the great feedback Gael. Comments below. On Thu, Mar 5, 2009 at 11:00 AM, Gael gael.marti...@gmail.com wrote: On Wed, Mar 4, 2009 at 9:06 AM, Jeff Victor jeff.j.vic...@gmail.com wrote: Some questions: 1. Do you

Re: [zones-discuss] Zone in a pset with high load generating high packet loss at the frame level

2009-03-05 Thread Jeff Victor
On Thu, Mar 5, 2009 at 1:48 PM, Steve Lawrence stephen.lawre...@sun.com wrote: On Thu, Mar 05, 2009 at 01:22:25PM -0500, Jeff Victor wrote: On Thu, Mar 5, 2009 at 11:00 AM, Gael gael.marti...@gmail.com wrote: On Wed, Mar 4, 2009 at 9:06 AM, Jeff Victor jeff.j.vic...@gmail.com wrote:

Re: [zones-discuss] Zone in a pset with high load generating high packet loss at the frame level

2009-03-05 Thread Steve Lawrence
On Thu, Mar 05, 2009 at 04:12:19PM -0500, Jeff Victor wrote: On Thu, Mar 5, 2009 at 1:48 PM, Steve Lawrence stephen.lawre...@sun.com wrote: On Thu, Mar 05, 2009 at 01:22:25PM -0500, Jeff Victor wrote: On Thu, Mar 5, 2009 at 11:00 AM, Gael gael.marti...@gmail.com wrote: On Wed, Mar 4,

Re: [zones-discuss] Zone in a pset with high load generating high packet loss at the frame level

2009-03-04 Thread Jeff Victor
I have received several private comments expressing interest in this topic, so I'd like to generate more discussion and attempt to focus on a solution that meets most or all of the needs. Summary of problem: - A zone can be configured so that its processes do not run on the CPUs in the

Re: [zones-discuss] Zone in a pset with high load generating high packet loss at the frame level

2009-03-03 Thread Jeff Victor
Hello Gael, On Mon, Mar 2, 2009 at 10:08 PM, Gael gael.marti...@gmail.com wrote: Hello Got a zone running SAS with cpu capping enabled using a processor set as we see a few processes using quite a bit of cpu there too often. Is that zone assigned to a resource pool, or is it using the

Re: [zones-discuss] Zone in a pset with high load generating high packet loss at the frame level

2009-03-03 Thread Gael
Many thanks to Bob Netherton and Jeff for their quick help on that painful issue. The solution was to use psrset -f on the heavily used pset. It is fully supported and a recommended situation when CPU starvation causes interrupts not to be serviced in time and they get lost. Credit goes to

Re: [zones-discuss] Zone in a pset with high load generating high packet loss at the frame level

2009-03-03 Thread Jeff Victor
On Tue, Mar 3, 2009 at 8:39 PM, Gael gael.marti...@gmail.com wrote: Many thanks to Bob Netherton and Jeff for their quick help on that painful issue. The solution was to use psrset -f on the heavily used pset. It is fully supported and a recommended situation when CPU starvation causes