RE: Running jobs on a separate core -- MIDRANGE-L

Paul,

If the QZDASOINIT and QSQSRVR jobs can be defined there, (I have never tried
it and honestly don't know if it can be done) then yes in this case workload
groups would allow the OP to limit those jobs to a single processor.

Based on some other information in this thread, I highly doubt this is the
way to do it however, since there is index activity going on and the base
tuning for these two jobs has not been accomplished. Besides, with two
cores running adding the extra threads, it would defeat some of DB/2s most
excellent features to limit it. I think in this case proper prior tuning of
DB/2 is called for. (proper work management and indexing strategy)

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Thursday, May 22, 2014 10:38 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Running jobs on a separate core

Would Workload groups be a solution, I've never used them.

Setting up workload groups
A workload group defines the number of processor cores that can be used
concurrently by jobs and threads that are associated with the group. Product
entries can be added to a workload group to define the license term and
feature of the product in the group. To set up workload groups, use the
character-based interface.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Charles Wilt
Sent: Thursday, May 22, 2014 11:14 AM
To: Midrange Systems Technical Discussion
Subject: Re: Running jobs on a separate core

Interesting that the system didn't create it as a MTI...

Charles

On Thu, May 22, 2014 at 10:44 AM, DrFranken <midrange@xxxxxxxxxxxx> wrote:

Index activity is an ongoing issue....it seems like we are forever

creating new indexes (and it appears we are recreating these on a
continual basis for the same index).

Well there's half your problem! Creating indexes isn't bad, constantly
re-creating them is VERY bad. Use the Index adviser and these should
stick out like sore thumbs!

We once created an index that took only 1 second to create yet it
dropped system wide CPU usage by TWENTY Percent! How can that be you
say? It was needed by every single query from their web site!! The
index adviser nearly cried out to create that one!

- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com

On 5/22/2014 10:03 AM, Brian Piotrowski wrote:

Thanks, Jim.

Index activity is an ongoing issue....it seems like we are forever
creating new indexes (and it appears we are recreating these on a
continual basis for the same index).

With that said has anyone taken the IBM course "IBM DB2 for i SQL
Performance Monitoring, Analysis and Tuning" and found any value from it?

Thanks!

/b;

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf
Of Jim Oberholtzer
Sent: Thursday, May 22, 2014 10:00 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Running jobs on a separate core

I don't know if a processor group will work in this case because
ordinarily the license program is set to run in a processor group.
Having not tried to push the QZDASOINIT and/or QSQSRVR jobs into one,
I don't know if it can be done (Domino and WAS can be pushed into one).

Look into processor groups, only because you have more than one

processor.

Also in your performance investigations remember to look at index
activity.
Unless this box is just stressed with workload, I usually find quite
a bit of temporary index activity in situations like the one you

describe.

You should also see quite a bit of I/O activity on the disk units if
indexing is going on too.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf
Of rob@xxxxxxxxx
Sent: Thursday, May 22, 2014 8:47 AM
To: Midrange Systems Technical Discussion
Subject: Re: Running jobs on a separate core

Now there's an oxymoron: "new 400".

I don't believe there is a way to dedicate out processors like you
can memory. With memory, you can bust it up into subsystems and
whatnot. This has been around since, well, back on 400's.
About the only way to dedicate processors is to create separate
partitions.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600
Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: Brian Piotrowski <bpiotrowski@xxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion (midrange-l@xxxxxxxxxxxx)"
<midrange-l@xxxxxxxxxxxx>
Date: 05/22/2014 09:26 AM
Subject: Running jobs on a separate core
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

All,

In the next month or so our new 400 will be delivered to us. The new
box will have two cores because right now our single core machine is
being crushed by the QZDASOINIT jobs (they occupy anywhere from 75% -
90% of the CPU utilization at any given time).

Yes, we are investigating the reasons why these jobs are occupying so
much, but I wanted to know if there's a way I can dedicate a core to
a specific job or subsystem? I would like to move the web jobs off
to their own core so the other core can focus on taking care of the other

tasks.

Any advice or recommendations would be appreciated.

Thankee-sai!

/b;

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Brian Piotrowski
Manager - I.T.
Simcoe Parts Service, Inc.
Ph: 705-435-7814 x343
Fx: 705-435-5029
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
http://www.simcoeparts.com<http://www.simcoeparts.com/>

Please consider the environment. Don't print this e-mail unless you
really need to.

The information contained in this communication is confidential and
intended only for the use of those to whom it is addressed. If you
have received this communication in error, please notify me by
telephone (collect if necessary) and delete or destroy any copies of it.

Thank you!

--

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.