Re: IO TIME vs COMputable.
On Nov 2, 10:57 am, "news.rd.francetelecom.fr" <e...@f.gf> wrote:[color=blue]
> Hello,
>
> I am looking for the reel IO time for a batch.[/color]
Why? What problem are you really trying to solve?
I find it much more fruitful to find out what the IOs are and do
something about it then to know how long they take. The fastest IO is
one never done, and better still... one never even considered.
[color=blue]
> It's seem at the end of the batch report, there is information like :
> Charged CPU time: 0 00:10:21.34 Elapsed time: 0 00:25:18.93
> i know that the IO time = ELapsed - CPU Time.[/color]
That's often good enough to know whether there is something to be
done.
Of course you'd also want to know the direct and buffered io count.
[color=blue]
> But , if the batch wait the processor (COMputable state) during the
> executing, the IO time was wrong. (i think)[/color]
It's not IO time, it is waiting time.
Could be waiting for resources, events, synchronization, data,
whatever.
For batch jobs,(Disk) IO is often a large component,
but a disproportionally large IO delay coudl come from a few, slow,
network IOs.
Maybe the batch job triggers heavy Oracle queries?
You correctly identify the scheduling state COM but not CUR as looking
like IO time.
But there is also waiting for implicit (RMS bucket / XQP ) Locks
around IOs..
Furthermore, IF you batch jobs go COM, then the system is overloaded
already.
If you are thinking of speeding up the IO, then the same job is likely
to simply spend more time in COM state versus LEF state. On the other
hand, if you could avoid doing the IO, it is a win-win for all
involved.
That could be as simple as pre-extending output file and using larger
buffers.
[color=blue]
> how can i find the reel "IO TIME" ou COMputable TIME for the batch process.[/color]
There is no fool proof way that I can quickly think of.
If you are very curious, and have nothing better to do, then you could
consider sampling the process states for a while, maybe 10 times per
second and just count CUR, COM, LEF and HIBER to get a distribution
picture.
Also note that some of the COM/CUR time can be hiding active IOs,
notably when work with RMS options like Deferred Write, Write-Behind
and Read-Ahead.
And also note that some (most READ) IOs could easily be resolve from
cache while the process is CUR.
[color=blue]
> or i am wrong in my reasoning ?[/color]
Focus on the real problem, on the real activities, use the numbers
just as indicator, helpers, not the goal itself.
Hope this helps some,
Hein van den Heuvel ( at gmail dot com )
HvdH Performance Consulting
Re: IO TIME vs COMputable.
On Nov 2, 10:57 am, "news.rd.francetelecom.fr" <e...@f.gf> wrote:[color=blue]
> Hello,
>
> I am looking for the reel IO time for a batch.
>
> It's seem at the end of the batch report, there is information like :
> Charged CPU time: 0 00:10:21.34 Elapsed time: 0 00:25:18.93
>
> i know that the IO time = ELapsed - CPU Time.
>
> But , if the batch wait the processor (COMputable state) during the
> executing, the IO time was wrong. (i think)
>
> how can i find the reel "IO TIME" ou COMputable TIME for the batch process.
>
> is this information available?
> or i am wrong in my reasoning ?
>
> Thanks you.
> Best regards
> Eric[/color]
Eric,
You are correct. IO time DOES NOT equal the difference between CPU
time and Elapsed time.
There are many reasons why this is so, including:
- job being COMputable but not active (partially noted in the
orginal post)
- buffered IO on sequential files (which proceeds asynchronously
while the job is executing)
- the effects of the disk caches
I agree with Hein, the numbers are a guide (and there are many more
than just the ratio between CPU and Elapsed time). The overall system
performance is the goal.
There are many things that can be tuned in the application, as I have
noted in my presentations including the one on "Applications Tuning on
OpenVMS" (the slides from which are admittedly among the back material
that I have not yet posted to my site)
- Bob Gezelter, [url]http://www.rlgsc.com[/url]
