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



Hi John

From memory you'll find the timeslice value in the subsystem class or Job
description.

If the system performs well with 10 jobs but not 25 then my advice is: leave
it at 10.

There is a law of diminishing returns that applies when running multiple
tasks at the same time; simply measure the total elapsed time it takes a for
a given number of jobs to run with the different job queue settings and
compare the results to determine what the optimum number to run in parallel
is.

Measuring the throughput will help you to understand what settings work best
for your system and will help you avoid just "twiddling the knobs" in the
hope of something good happening by luck or co-incidence. You want your
results to be consistent over the longer haul although results may vary from
day to day depending on other workloads. If you understand the best settings
you can then try and adjust for circumstances when required then put things
back for the normal workload.

You may want to consider moving the jobs out of *BASE to make them easier to
manage and to ensure they have exclusive access to some memory.

Don't ignore the other workloads on the system; include them in your
performance goals and management. You may be able to ensure more resources
for these tasks by appropriately managing or rescheduling other tasks on the
system - for instance programmers recompiling interactively ;)

You may also find that running multiple jobs using the same application is
causing an issue, depending on how the application is designed. If possible
this should be reviewed.

For example, if you are running multiple variations of the same job then you
may well be opening and closing the same tables repeatedly which is not the
most efficient approach although it can be viewed (by some) as easier to
code. Maybe having a server job or multiple server jobs waiting on data
queues could be of more help to you with throughput, although re-design may
not be an option for you.

Hope this helps.

Regards
Evan Harris




-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John Allen
Sent: Tuesday, 2 June 2009 8:00 a.m.
To: MIDRANGE-L@xxxxxxxxxxxx
Subject: Multiple jobs running out of single JOBQ are very slow

First off I am not even close to a guru on system
performance tuning.

I know just enough to be dangerous



So I am hoping someone here can at least point me in a
direction to get me started on this issue.



I have a JOBQ with Max Active set to 25

Running out of Pool Id 2 (*BASE)

*BASE has 1603MB memory with max active 109

% System ASP used is 79%

I cannot seem to find where the time slice value is set so I
cannot verify the value



There could be up to 25 jobs submitted into the JOBQ to run
at any given time



If there are only 10 jobs running at the same time, they all
run very quickly (less then a minute)

But as I increase the number of jobs running at the same
time, they slow way down (10-20 minutes each)

(And they are not processing anything)

Almost seems like they are all fighting for resources and
none of them complete

When I do wrkactjob the system CPU is 14% and the jobs CPU%
vary from .0 to .2 to .4



I cannot have them run single thread (or whatever 10 thread
is called) I have to allow for up to 25 running at the same
time



These jobs are running at priority 50 (because another
programmer said they were using up the system resources and
"slowing everything down")



I can change the jobq to run 10 at a time and they speed up
to the expected speed based on the little processing they
are doing

so I think it must be some system setting I need to adjust
to improve the jobs performance without affecting the
interactive jobs.



Any pointers?





Thanks in advance



John




As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.