Re: jobs running in one subsystem take up more CPU then rest of jobs

[John Jones <chianime@xxxxxxxxx>]

You can go over 100% in a partitioned environment.  Example: You have a
single-CPU machine.  An LPAR is defined as having 0.5 CPU Desired but 1 CPU
Maximum.  Partitions are uncapped so they can borrow unused CPU from other
partitions.  100% usage = fully using the Desired CPU.  >100% is achieved by
borrowing unused CPU from other LPARs.  The sample LPAR could hit 200% if
none of the other LPARs need any CPU.

On Thu, Nov 19, 2009 at 10:42 AM, Bob P. Roche <BRoche@xxxxxxxxxxxxxxxxx>wrote:

> Where do you see those numbers, I'm used to XXX if it's running 100% or
> more.
>
>
>
> From:
> <rob@xxxxxxxxx>
> To:
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Date:
> 11/19/2009 10:41 AM
> Subject:
> Re: jobs running in one subsystem take up more CPU then rest of jobs
> Sent by:
> <midrange-l-bounces@xxxxxxxxxxxx>
>
>
>
> 100% tops is for wimps
> CPU %:   127.8
> I've seen it a lot higher...
>
>
> Rob Berendt
> --
> Group Dekko Services, LLC
> Dept 01.073
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> From:   Charles Wilt <charles.wilt@xxxxxxxxx>
> To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Date:   11/19/2009 11:22 AM
> Subject:        Re: jobs running in one subsystem take up more CPU then
> rest of jobs
> Sent by:        midrange-l-bounces@xxxxxxxxxxxx
>
>
>
> John,
>
> If the users aren't complaining and the total CPU usage is less than
> 100%, then don't worry about how much the batch jobs are taking.
>
> Look at it this way, if the CPU isn't 100%, then part of the time your
> system is doing nothing....so how much did you pay for that
> paperweight anyway? :)  Theoretically, you want the system to run at
> 95% or so all day long. Of course in real life, you've got workload
> peaks & valleys, plus you want room for growth so you're not upgrading
> every week.
>
> The point is, why would you want to constrain the work being done for no
> reason?
>
> Charles
>
>
>
> On Thu, Nov 19, 2009 at 10:48 AM, John Allen <jallen@xxxxxxxxxxx> wrote:
> > I know this question will probably have multiple answers including "it
> > depends"
> >
> >
> >
> > If we have a subsystem setup to run a set of specific batch jobs. And
> these
> > jobs are running at the default batch job run priority of 50
> >
> > (subsystem setup with normal default values you get when subsystem is
> > created and the SBMJOB does not have anything but the default values
> > specified)
> >
> >
> >
> > The interactive jobs are running at the default priority of 10
> >
> >
> >
> > Why do the Batch jobs (there are 5 of them total running in the
> subsystem)
> > seem to be taking up to 60-70% of CPU while the interactive jobs are
> taking
> > .5 - 1% each
> >
> > Or is this nothing to worry about, the System i will adjust resources as
> > necessary to keep the interactive response time unaffected by batch
> jobs?
> > I do not have users complaining about slow response times (yet) I just
> > noticed this and it got me wondering why is this?
> >
> > And who knows if it continues they may start calling me.
> >
> >
> >
> > Also, is there something I can easily so to reduce the CPU% the batch
> jobs
> > are taking?
> >
> > Tmeslice, or memory or anything else?
> >
> >
> >
> > Thanks
> >
> > John
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.