RE: Processing Unit Time

["Schutte, Michael D" <Michael_Schutte@xxxxxxxxxxxx>]

Sorry to mislead you.  That 70% was the entire system not the job. The job was consistently under 1% 

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Loyd Goodbar
Sent: Tuesday, December 21, 2010 11:43 AM
To: Midrange Systems Technical Discussion
Subject: Re: Processing Unit Time

What do your paging and faults look like? How large is the generated CGIDEV2
document? Disk arms and utilization percentage? How long does the process
take if you exclude the CGIDEV2 items? Are you making other disk operations
(additional reads, writes or updates) aside from this SQL? Given that your
CPU usage is 70%, this seems to indicate the process may be disk-bound.

Loyd

On Tue, Dec 21, 2010 at 10:15 AM, Schutte, Michael D <
Michael_Schutte@xxxxxxxxxxxx> wrote:

> No the access plan isn't getting updated on each call.  It was last saved
> at 10:28:05  That's when the program started, it finished at 21:34.   I
> suppose I cannot count. It only took 11 hours not 12.  Haha.   I believe
> yesterday this sql statement was executed for every active retail item
> (20,000 items) and for the past 12 months.  So 20,000 * 12 = 240,000 times
> the statement ran.  After every call to sql statement, I'm executing
> updHTMLvar and WrtSection.  I know that this would slow the process overall.
>
> Thinking back, this was probably poor design, but it wasn't really intended
> to run for all items and all vendors, even though the prompt program allows
> the user to do so. But still, I can live with CPU time of 1448 seconds,
> cannot live with 11 hours of actual run time. This is what I don't
> understand.