meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?

Soo Lee

meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?
I have some questions.
What is the exact meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?

Which is right, VDWQT=0 makes I/O more frequently or
VDWQT=0 makes I/O less frequently ?

please, help me...



Db2 fan

Re: meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?
(in response to Soo Lee)
VDWQT at 0 means you will be Dequeuing 32 pages when 40 pages that belong
to the same dataset fills a virtual bpool. The effect of it depends on the
system configuration especially I/O sub system. Certainly it increases CPU
time. Recently by mistake our production system was set up with 0 which
resulted in a substantial CPU time with spikes of upto 60%. It actually
means more frequent little write I/O rather than less frequent large I/O. A
lot of people have different opinion on this. My take is, if the number of
pages written per I/O is not drastically less, do not try to lower this.
The key here is to avoid a large burst of I/O at anytime, but more
specifically at checkpoint.

Castout threshold applies to the coupling facility. In each Group buffer
pool there is a fixed queue of cast out class queue. when a page is to be
written to a queue, it must also tell which queue the page belongs to. Same
pageset pages are always grouped to the same class.
If the cast out class threshold is exceeded, the system which is the owner
of the cast out class will initiate the cast out of Pageset. The default is
10%. This is checked everytime a coupling facility write is performed.
DB2 fan



Joel Goldstein

Re: meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?
(in response to Db2 fan)
Using VDWQT of 0 will rarely have any effect on the overall number
of I/Os, or the CPU time.
Most systems and pools have a low number of avg pages/write (<5),
and when this is he case there will be no increase of CPU. Most systems
I look at avg <3 pages/write. So when write gets triggered, the number of
I/Os does not change with a low vdwqt..... it just smoothes them out,
or causes a "trickle" write.
Lowering vdwqt to 0 avoids flooding the system with I/Os when Db2
takes a checkpoint - and this flooding usually causes large spikes
in I/O response times for the online transactions.
See my presentation from IDUG this year for a graph showing this effect.
Regards,
Joel

Message text written by DB2 Data Base Discussion List
>VDWQT at 0 means you will be Dequeuing 32 pages when 40 pages that belong
to the same dataset fills a virtual bpool. The effect of it depends on the
system configuration especially I/O sub system. Certainly it increases CPU
time. Recently by mistake our production system was set up with 0 which
resulted in a substantial CPU time with spikes of upto 60%. It actually
means more frequent little write I/O rather than less frequent large I/O. A
lot of people have different opinion on this. My take is, if the number of
pages written per I/O is not drastically less, do not try to lower this.
The key here is to avoid a large burst of I/O at anytime, but more
specifically at checkpoint.

Castout threshold applies to the coupling facility. In each Group buffer
pool there is a fixed queue of cast out class queue. when a page is to be
written to a queue, it must also tell which queue the page belongs to. Same
pageset pages are always grouped to the same class.
If the cast out class threshold is exceeded, the system which is the owner
of the cast out class will initiate the cast out of Pageset. The default is
10%. This is checked everytime a coupling facility write is performed.<



Sanjeev (CTS) S

Re: meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?
(in response to Joel Goldstein)
Hi ,
I think what everyone is trying to point out in this thread is the "perfect
utilization of the write I/O", means if 32 pages can be written in one I/O
then why write 3 or 5 or less than that.
Please correct me if i misunderstood anything.

Regards
Sanjeev

> -----Original Message-----
> From: Joel Goldstein [SMTP:[login to unmask email]
> Sent: Wednesday, December 13, 2000 6:26 PM
> To: [login to unmask email]
> Subject: Re: meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?
>
> Using VDWQT of 0 will rarely have any effect on the overall number
> of I/Os, or the CPU time.
> Most systems and pools have a low number of avg pages/write (<5),
> and when this is he case there will be no increase of CPU. Most systems
> I look at avg <3 pages/write. So when write gets triggered, the number of
> I/Os does not change with a low vdwqt..... it just smoothes them out,
> or causes a "trickle" write.
> Lowering vdwqt to 0 avoids flooding the system with I/Os when Db2
> takes a checkpoint - and this flooding usually causes large spikes
> in I/O response times for the online transactions.
> See my presentation from IDUG this year for a graph showing this effect.
> Regards,
> Joel
>
> Message text written by DB2 Data Base Discussion List
> >VDWQT at 0 means you will be Dequeuing 32 pages when 40 pages that belong
> to the same dataset fills a virtual bpool. The effect of it depends on the
> system configuration especially I/O sub system. Certainly it increases CPU
> time. Recently by mistake our production system was set up with 0 which
> resulted in a substantial CPU time with spikes of upto 60%. It actually
> means more frequent little write I/O rather than less frequent large I/O.
> A
> lot of people have different opinion on this. My take is, if the number of
> pages written per I/O is not drastically less, do not try to lower this.
> The key here is to avoid a large burst of I/O at anytime, but more
> specifically at checkpoint.
>
> Castout threshold applies to the coupling facility. In each Group buffer
> pool there is a fixed queue of cast out class queue. when a page is to be
> written to a queue, it must also tell which queue the page belongs to.
> Same
> pageset pages are always grouped to the same class.
> If the cast out class threshold is exceeded, the system which is the owner
> of the cast out class will initiate the cast out of Pageset. The default
> is
> 10%. This is checked everytime a coupling facility write is performed.<
>
>
>
> http://www.ryci.com/db2-l. The owners of the list can be reached at
> [login to unmask email]
This e-mail and any files transmitted with it are for the sole use
of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message. Any unauthorised review, use, disclosure,
dissemination, forwarding, printing or copying of this email or any action taken in
reliance on this e-mail is strictly prohibited and may be unlawful.

Visit us at http://www.cognizant.com



Joel Goldstein

Re: meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?
(in response to Sanjeev (CTS) S)
Yes, but you have absolutely NO Control over how many pages are
written
for an I/O. Therefore, if the current avg pages/write is a single digit,
then
VDWQT should be lowered, and "usually" to ZERO - unless you are on V6
with a large pool.... then you can specify (0,xxx) where xxx is the number
of
pages that will trigger the write.
Regards,
Joel


Message text written by DB2 Data Base Discussion List
> I think what everyone is trying to point out in this thread is the
"perfect
utilization of the write I/O", means if 32 pages can be written in one I/O
then why write 3 or 5 or less than that.
Please correct me if i misunderstood anything.

Regards
Sanjeev<



Db2 fan

Re: meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?
(in response to Joel Goldstein)
I dont think it is anything to do with the utilization of I/O. I think it
is in the effective utilization of CPU. Incidentally I am looking at a
USENIX paper on the same subject.
The fact is 'Idleness is sloth'. You don't want the CPU to be idle at any
time. By triggering the I/O at frequent intervals, you are in essence
triggering additional processing. Now this is a very generalized statement
that would apply to all operating systems. In a typical large computing
environment I/O is handled by reduced instruction processors. The actual
CPU will not care to wait. But is the main processor that coordinates the
whole operation.
Indirectly it tends to help the write efficiency by eliminating the bursts
in the I/O operations.
VDWQT aids in eliminating the ripples in I/O and does not govern the I/O.
So average number of pages written per I/O would still not be changed. By
changing VDWQT you have not changed the I/O sub-system throughput. You have
only smoothed the whole operation.
DB2 fan



RICK (SBCSI) DAVIS

Re: meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?
(in response to Db2 fan)
Sanjeev,
This subject was pretty well covered in the archives; consensus of
opinions and experiences were to use "trickle out writes".

Joel,
I agree with you overall. However, we do have some control over the
number of pages written per I/O in that we can group (either on purpose or
accidentally) table/indexspace into bufferpools that have a good locality of
reference. This would tend to force pages written per I/O up. I don't think
I understand all I think I know about this fact as it relates to
VDWQT(0,nnn) and would be very interested in your opinion. Would it actually
be better to try to spread those types of 'spaces evenly throughout the
bufferpools?

Regards,
Rick Davis

"This e-mail and any files transmitted with it are the property of SBC,
are confidential, and are intended solely for the use of the individual
or entity to whom this e-mail is addressed. If you are not one of the
named recipient(s) or otherwise have reason to believe that you have
received this message in error, please notify the sender at 314-235-6854
and delete this message immediately from your computer. Any other use,
retention, dissemination, forwarding, printing, or copying of this
e-mail is strictly prohibited."



-----Original Message-----
From: Joel Goldstein [mailto:[login to unmask email]
Sent: Thursday, December 14, 2000 9:12 AM
To: [login to unmask email]
Subject: Re: meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?


Yes, but you have absolutely NO Control over how many pages are
written
for an I/O. Therefore, if the current avg pages/write is a single digit,
then
VDWQT should be lowered, and "usually" to ZERO - unless you are on V6
with a large pool.... then you can specify (0,xxx) where xxx is the number
of
pages that will trigger the write.
Regards,
Joel


Message text written by DB2 Data Base Discussion List
> I think what everyone is trying to point out in this thread is the
"perfect
utilization of the write I/O", means if 32 pages can be written in one I/O
then why write 3 or 5 or less than that.
Please correct me if i misunderstood anything.

Regards
Sanjeev<



http://www.ryci.com/db2-l. The owners of the list can be reached at
[login to unmask email]



RICK (SBCSI) DAVIS

Re: meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?
(in response to RICK (SBCSI) DAVIS)
DB2 Fan,
I agree, a MIP is a terrible thing to waste!
However, please consider this. An OS390 image running at 100+ percent most
of the time. Scheduling I/O takes the same amount of time regardless of how
much data is written per I/O. But, as data written per I/O goes up,
scheduling of more and more I/O tasks goes up due to wait. Thus, the
capacity of the I/O subsystem is the real key in the equation.
If I had a Shark_wiz_bang I/O subsystem I'd probably look at ways to
increase data written per I/O thus freeing up OS390 to get more "real" work
done.

HTH,
Rick Davis

"This e-mail and any files transmitted with it are the property of SBC,
are confidential, and are intended solely for the use of the individual
or entity to whom this e-mail is addressed. If you are not one of the
named recipient(s) or otherwise have reason to believe that you have
received this message in error, please notify the sender at 314-235-6854
and delete this message immediately from your computer. Any other use,
retention, dissemination, forwarding, printing, or copying of this
e-mail is strictly prohibited."



-----Original Message-----
From: DB2 fan [mailto:[login to unmask email]
Sent: Thursday, December 14, 2000 9:37 AM
To: [login to unmask email]
Subject: Re: meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?


I dont think it is anything to do with the utilization of I/O. I think it
is in the effective utilization of CPU. Incidentally I am looking at a
USENIX paper on the same subject.
The fact is 'Idleness is sloth'. You don't want the CPU to be idle at any
time. By triggering the I/O at frequent intervals, you are in essence
triggering additional processing. Now this is a very generalized statement
that would apply to all operating systems. In a typical large computing
environment I/O is handled by reduced instruction processors. The actual
CPU will not care to wait. But is the main processor that coordinates the
whole operation.
Indirectly it tends to help the write efficiency by eliminating the bursts
in the I/O operations.
VDWQT aids in eliminating the ripples in I/O and does not govern the I/O.
So average number of pages written per I/O would still not be changed. By
changing VDWQT you have not changed the I/O sub-system throughput. You have
only smoothed the whole operation.
DB2 fan








Db2 fan

Re: meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?
(in response to RICK (SBCSI) DAVIS)
True, I agree. I neither disagreed with Joel in general. We all share the
same thought to reduce the burstiness in I/O but what I disagree with is
the fact that additional CPU cost would not be incurred by doing this. I
personally witnessed the CPU spike in DB2 when accidentally some of the
BPOOLs were changed to 0. We also had high Async write wait time.
So as you rightly said, it depends on the characterstics of I/O sub-system.
What if you have a poor I/O configuration and by turning on more frequent
little writes, the channel paths were clogged.
By playing with VDWQT you cannot change the static behaviour of I/O sub-
system, but you can influence the dynamic behaviour of the I/O sub-system.
Write efficiency would still be governed by the static behaviour of a given
I/O system and does not depend on the Dynamics we are discussing here.
DB2 fan..



Joel Goldstein

Re: meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?
(in response to Db2 fan)
First the primary thing to cosider is that number of writes overall will
not change,
when the avg pages/write is low. This will not clog the i/o subsystem.

Secondly, if you saw a cpu spike of 60% (or any large spike) this was NOT
from i/o.

Since the i/o does not change, there will be no increase of cpu.
Aditionally, if I remember my old calculations, about 160 i/o per SECOND
is about 1 MIP of cpu cost....
Increasing or decreasing i/o rarely has any "noticeable" effect on the
observed CPU
busy rate.... although it does have a cpu cost, and this can be converted
to $$.
Regards,
Joel

Message text written by DB2 Data Base Discussion List
>True, I agree. I neither disagreed with Joel in general. We all share the
same thought to reduce the burstiness in I/O but what I disagree with is
the fact that additional CPU cost would not be incurred by doing this. I
personally witnessed the CPU spike in DB2 when accidentally some of the
BPOOLs were changed to 0. We also had high Async write wait time.
So as you rightly said, it depends on the characterstics of I/O sub-system.
What if you have a poor I/O configuration and by turning on more frequent
little writes, the channel paths were clogged.
By playing with VDWQT you cannot change the static behaviour of I/O sub-
system, but you can influence the dynamic behaviour of the I/O sub-system.
Write efficiency would still be governed by the static behaviour of a given
I/O system and does not depend on the Dynamics we are discussing here.<



Joel Goldstein

Re: meaning of VDWQT=0 & CASTOUT CLASS THRESHOLD=0 ?
(in response to Joel Goldstein)
Rick,
Objects should normally be grouped by access type and working set to
optimize the
read access (eliminate read i/o). Basically, I don't worry about the
writes very much
as far as rtying to get more pages/write..... because your workload
probably varies
more per day in this aspect, and at different times of day, than the read
side.
In many cases vdwqt "might" be raised slightly for large sequentail batch
workloads
that have pages/write > 20. And you would have to monitor to see if it
increased
pages/write.... it might or might not.
This is especially relevant looking at large pools and using something like
vdwqt(0,80) just
as an example.
Regards,
Joel

Message text written by DB2 Data Base Discussion List
> I agree with you overall. However, we do have some control over
the
number of pages written per I/O in that we can group (either on purpose or
accidentally) table/indexspace into bufferpools that have a good locality
of
reference. This would tend to force pages written per I/O up. I don't think
I understand all I think I know about this fact as it relates to
VDWQT(0,nnn) and would be very interested in your opinion. Would it
actually
be better to try to spread those types of 'spaces evenly throughout the
bufferpools?<