× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks for everyone's input.
I am going to check and see if users are seeing a slow response times. (I
doubt it or my phone is broken because they would be calling)


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Bob P. Roche
Sent: Thursday, November 19, 2009 11:28 AM
To: Midrange Systems Technical Discussion
Subject: Re: jobs running in one subsystem take up more CPU then rest of
jobs

Also remember the batch job is doing something it's whole run, unless it's
waiting for a response from a remote server. The interactive job does
something, shows the user a screen and waits for them to finish with the
screen, then repeats that cycles. It's not always using CPU cycles.



From:
Charles Wilt <charles.wilt@xxxxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
11/19/2009 10: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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.