Re: CPU Percentage Flex, Lies, and Usage Measuring Tape

Neil,

In a message dated 97-07-28 19:58:52 EDT, you write:

> >  Despite my upping both jobs to priority 10, setting purge for both to
*NO,
>  > and setting both timeslices to 100,000, neither is consuming more than
18%
>  > CPU with nobody else on the systems.
>  > 
>  > Last week, we asked our Systems Engineering department for some help 
>  > with our
>  > BPCS conversion program's performance under the same circumstances, and 
>  > they did _something_ to make it run with more CPU percentage.  
>  
>  Increased the jobs TIMESLICE value or RUNPTY, and maybe there were other
>  competing jobs running at the same time and therefore an increase may
>  have helped here ?

Other jobs were a consideration at that time, but we had already increased
the RUNPTY and TIMESLICE ourselves.

<<snip>>
>  
>  Check system value QDYNPTYSCD on RISC system.

It was on on the RISC, our SE's are looking into it now.

>  What is sysval QPFRADJ set to now vs. then ?

'0' in both instances.

>  Is the 'expert cache' (Paging option *CALC, from F11 on WRKSYSSTS) set
>  for the pool you are running the batch job in ?

*FIXED

>  Changing you priority to 10 isn't going to do a thing for you if there
>  are no other jobs competing for the CPU between priorities 10 and 50 at
>  the same time.
>  
>  Never mind the CPU usage of the job, how long is the job taking to
>  complete now vs. what it took before ?  Is it still quicker than it was?
>  With a faster CPU on the new machine a job that may have been CPU bound
>  could now become disk bound, and unable to eat as many of the new faster
>  CPU cycles as it it could the slower cycles on the old system.
>  Were there any changes made to the disk configurations ?

Actually, based upon our benchmarks from when the Production box was a 320,
it's running much slower now.  I think that I failed to mention that this is
an SQLRPG.  The program used to start out slowly in Transactions per Minute,
but gain speed as it progressed through the database.  Now it seems to remain
at a constant TPM rating throughout its duration.  Add to this the fact that
the disk arms nearly doubled when we upgraded, and the speed becomes even
more confusing (note that this was a MOVE rather than an upgrade, so we don't
have the old disks getting more I/O than the new ones).

Interesting point about the "binding" shift though.  It's entirely possible
that the program is now just "doing all that it can do", although that
doesn't explain the slower performance (other than the fact that it's an OPM
program).  I'll keep trying...

Thanks!

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@AOL.COM

"There is no abstract art.  You must always start with something." -- Pablo
Picasso
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *