Re: Timeslice/purge settings was: Suppress Query Status Message

When job does disk I/O, it is a short wait (disk I/O is relatively fast
operation), so job will not leave activity level.
But what is more important, is if disk I/O is synchronous or asynchronous.
Asynch I/O is perfromed by system tasks out of line, so job does not need
to wait for I/O completion. Asynch I/Os come in all flavours - asynch
pageouts, prefetches etc.
One should take all possible measures to make sure that most of I/Os are
asynch - it makes *huge* difference in performance.

Timeslice comes hand in hand with purge, because with PURGE(*YES) at
timeslice end the whole PAG will be paged out.
My opinion is that with memory size no longer a constraint (comparative to
older times), PURGE should be always *NO.

Generally making timeslice shorter will make response time more uniform
between a multitude of jobs on system, but it will not decrease runtime of
a long-running task.

I would say, that most important tuning parameters are RUNPTY and size of
memory pool, where job runs.
Building of access path is aggressive memory user - in other words, the
larger the memory pool, the better it performs. And the difference can be
an order of magnitude. So if one often runs queries which build access
paths, make sure that they have plenty of memory.
Of course, one has to take into account other workload on system - there
are trade-offs to be made.

Best regards
    Alexey Pytel



"Buck Calabro/commsoft" <mcalabro@commsoft.net> on 03/18/99 08:26:24 AM

Please respond to MIDRANGE-L@midrange.com

To:   MIDRANGE-L@midrange.com
cc:    (bcc: Alexei Pytel/Rochester/IBM)
Subject:  Timeslice/purge settings was: Suppress Query Status Message





On 03/17/99 05:46:43 PM pytel wrote:

Alexey,

>Timeslice and Purge settings will not have any noticable influence on
>long-running tasks.

This is a very interesting topic!
Doesn't TIMESLICE come into play when you have a compute-bound job?
Something like creating large GDDM graphics?  When the job goes to disk to
get/put a record, it leaves the activity level, right?  Unless the job
occupies the activity level until timeslice end, boosting the timeslice
makes no difference

The purge setting is mostly useful in a small-memory system, if I recall.
It lets you tell the system if you want the entire PAG paged in one
operation at timeslice end/enter long wait.

This leaves RUNPTY as the other parameter on the class.  Won't a job that
fetches thousands of pages of DASD at RUNPTY(20) will be more of a resource
hog than the same job running at 50?  It'll certainly get returned to an
activity level before the RUNPTY(50) job will.

So, I guess the question here is: for a query, does the processor time
required to build an access path get charged to the interactive job, or to
an internal system task?

The batch/interactive debate extends into separate memory pools and working
set size.  Too often, the interactive memory pool is sized for a smaller
working set that the batch pools.  This makes it easier for a batch-type
job to force other jobs' storage to be paged out.  This is not a Good Thing
for the interactive job's program pages that've been paged out by DB pages.

>Suppressing status messages can help, because sending message to display
>device incurs a relatively high overhead (especially when there are many).

Absolutely!  The same is true for writing messages to the job log.  Any
time a program/job does extra I/O is a place to look for performance
improvements.

Buck Calabro
Billing Concepts Inc (formerly CommSoft), Albany, NY
mailto:mcalabro@commsoft.net
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---