MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » May 2014

RE: Running jobs on a separate core



fixed

I always move all non-IBM i processing (SQL and ODBC are great examples) out
of *BASE and leave only what absolutely has to run there. Subsystem
monitors are a great example of what should be there. Every subsystem
should have at least two memory pools. Pool 1 is *BASE and the subsystem
monitor runs there. All the workload the subsystem runs should be moved to
a shared pool (subsystem memory pool 2 etc.).

Now you can take it to extremes, such as FTP. If there is only periodic FTP
traffic, then leave it. Same thing with some of the other light load
functions, but certainly interactive, batch, HTTP serving, SQL of any
variety, etc. should be moved out.

The theory here is IBM i and licensed program products use *MACHINE and
*BASE. If you have user workload that competes with IBM i or its various
pieces/parts, then the whole system slows down due to the contention.

It also depends on how much memory you have. If there is not really
sufficient memory to tune with (IE: any system with less than about 6GB of
memory) then you can starve all the pools for memory which of course is
equally bad.

BTW: As delivered by IBM subsystem QSERVER only has one subsystem pool,
*BASE. If there is a second pool someone modified it, albeit incorrectly.

--
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 2:47 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Running jobs on a separate core

Jim,

By default, QZDASOINIT and QSQSRVR run in QUSRWRK, pool 2, which is *BASE.
Should this be changed in all cases, or only if one is experiencing
performance issues.

Paul

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

Without doubt QZDASOINIT and QSQSRVR jobs should be in a subsystem by
themselves with a shared pool attached. You can do that right now before
the box arrives and potentially save some grief. No reason to wait on that
one.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


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

Thanks, Rob.

In reviewing various documents a lot of them point to creating a new
subsystem and pushing the QZDASOINIT jobs onto it. I guess it's something
we'll have to investigate once the new box arrives.

We would have purchased one of the new i8 boxes coming out next month, but
our applications are unproven on 7.1 and I wasn't going to risk having a
primary box with untested apps on it.

/b;

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Thursday, May 22, 2014 9: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.


--
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.







Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact