IDS performance
A user asked why 'cached writes' in onstat -p was only ~70% on one box while similar machines showed 92-94%, and whether this signalled a performance problem (he'd previously had disk trouble with very high sar -d avque, since fixed, but the low write-cache figure remained). Madison Pruet advised judging the buffer read:write ratio first, since write cache rate depends heavily on application behaviour and rows per page; he suggested very low LRU_MIN/MAX_DIRTY settings (e.g. 0/0) force immediate flushing, and sequential scans can flush the pool (check onstat -b). Alexey Sonkin added that for batch/cleanup work write caching does matter and LRU_MAX/MIN_DIRTY should never be below 2/1. No confirmed resolution for the original system is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi to all,
A short question: from the output of the onstat -p for the Êched writes I have
69,9%. I beleave this is very bad! What this number should be to have a good
performance ? (>90%?). What might be a problem for such a low performance?
On other machines I have at least 94%! Please comment on this number and what
it means! Is IDS performing ok with this number beeing so low?
Dejan.
--0__=09BBE470DFEEE1E18f9e8a93df938690918c09BBE470DFEEE1E1
Content-type: multipart/alternative;
Boundary="1__=09BBE470DFEEE1E18f9e8a93df938690918c09BBE470DFEEE1E1"
--1__=09BBE470DFEEE1E18f9e8a93df938690918c09BBE470DFEEE1E1
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
I wouldn't worry about the write cache rate as much as the read cache r=
ate.
The write cache rate is highly dependent on what the application is doi=
ng,
the size of the rows, and how often updates are actually occuring. For=
example, if the row is large enough so that only one row can be written=
per
page, then your write cache rate is going to be very low.
=
"DEJAN STOJC...." =
<dejan.stojcevski =
@cosmofon.com.mk> =
To
Sent by: ids@iiug.org =
forum.subscriber@ =
cc
iiug.org =
Subj=
ect
IDS performance [3304] =
08/01/2004 11:32 =
AM =
=
=
=
=
Hi to all,
A short question: from the output of the onstat -p for the =CAched writ=
es I
have 69,9%. I beleave this is very bad! What this number should be to h=
ave
a good performance ? (>90%?). What might be a problem for such a low
performance?
On other machines I have at least 94%! Please comment on this number an=
d
what it means! Is IDS performing ok with this number beeing so low?
Dejan.
=
--1__=09BBE470DFEEE1E18f9e8a93df938690918c09BBE470DFEEE1E1
Content-type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable
<html><body>
<p>I wouldn't worry about the write cache rate as much as the read cach=
e rate. The write cache rate is highly dependent on what the applicati=
on is doing, the size of the rows, and how often updates are actually o=
ccuring. For example, if the row is large enough so that only one row =
can be written per page, then your write cache rate is going to be very=
low. <br>
<br>
<br>
<img src=3D"cid:10__=3D09BBE470DFEEE1E18f9e8a93df938@us.ibm.com" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for "DEJAN STOJC..=
.." <dejan.stojcevski@cosmofon.com.mk>">"DEJAN STOJC...=
." <dejan.stojcevski@cosmofon.com.mk><br>
<br>
<br>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">=
<tr valign=3D"top"><td style=3D"background-image:url(cid:20__=3D09BBE47=
0DFEEE1E18f9e8a93df938@us.ibm.com); background-repeat: no-repeat; " wid=
th=3D"40%">
<ul>
<ul>
<ul>
<ul><b><font size=3D"2">"DEJAN STOJC...." <dejan.stojcevsk=
i@cosmofon.com.mk></font></b><font size=3D"2"> </font><br>
<font size=3D"2">Sent by: forum.subscriber@iiug.org</font>
<p><font size=3D"2">08/01/2004 11:32 AM</font></ul>
</ul>
</ul>
</ul>
</td><td width=3D"60%">
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">=
<tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3=
0__=3D09BBE470DFEEE1E18f9e8a93df938@us.ibm.com" border=3D"0" height=3D"=
1" width=3D"58" alt=3D""><br>
<div align=3D"right"><font size=3D"2">To</font></div></td><td width=3D"=
100%"><img src=3D"cid:30__=3D09BBE470DFEEE1E18f9e8a93df938@us.ibm.com" =
border=3D"0" height=3D"1" width=3D"1" alt=3D""><br>
<font size=3D"2">ids@iiug.org</font></td></tr>
<tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3=
0__=3D09BBE470DFEEE1E18f9e8a93df938@us.ibm.com" border=3D"0" height=3D"=
1" width=3D"58" alt=3D""><br>
<div align=3D"right"><font size=3D"2">cc</font></div></td><td width=3D"=
100%"><img src=3D"cid:30__=3D09BBE470DFEEE1E18f9e8a93df938@us.ibm.com" =
border=3D"0" height=3D"1" width=3D"1" alt=3D""><br>
</td></tr>
<tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3=
0__=3D09BBE470DFEEE1E18f9e8a93df938@us.ibm.com" border=3D"0" height=3D"=
1" width=3D"58" alt=3D""><br>
<div align=3D"right"><font size=3D"2">Subject</font></div></td><td widt=
h=3D"100%"><img src=3D"cid:30__=3D09BBE470DFEEE1E18f9e8a93df938@us.ibm.=
com" border=3D"0" height=3D"1" width=3D"1" alt=3D""><br>
<font size=3D"2">IDS performance [3304]</font></td></tr>
</table>
<table border=3D"0" cellspacing=3D"0" cellpadding=3D"0">
<tr valign=3D"top"><td width=3D"58"><img src=3D"cid:30__=3D09BBE470DFEE=
E1E18f9e8a93df938@us.ibm.com" border=3D"0" height=3D"1" width=3D"1" alt=
=3D""></td><td width=3D"336"><img src=3D"cid:30__=3D09BBE470DFEEE1E18f9=
e8a93df938@us.ibm.com" border=3D"0" height=3D"1" width=3D"1" alt=3D""><=
/td></tr>
</table>
</td></tr>
</table>
<br>
<tt>Hi to all,<br>
A short question: from the output of the onstat -p for the =CAched writ=
es I have 69,9%. I beleave this is very bad! What this number should be=
to have a good performance ? (>90%?). What might be a problem for s=
uch a low performance?<br>
On other machines I have at least 94%! Please comment on this number an=
d what it means! Is IDS performing ok with this number beeing so low?<b=
r>
Dejan.<br>
<br>
</tt><br>
</body></html>=
--1__=09BBE470DFEEE1E18f9e8a93df938690918c09BBE470DFEEE1E1--
--0__=09BBE470DFEEE1E18f9e8a93df938690918c09BBE470DFEEE1E1
Content-type: image/gif;
name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <10__=09BBE470DFEEE1E18f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64
R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7
--0__=09BBE470DFEEE1E18f9e8a93df938690918c09BBE470DFEEE1E1
Content-type: image/gif;
name="pic23345.gif"
Content-Disposition: inline; filename="pic23345.gif"
Content-ID: <20__=09BBE470DFEEE1E18f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64
R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA
AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh
EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR
RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH
LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK
BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI
TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR
M00oQ
--0__=09BBE477DFC299EE8f9e8a93df938690918c09BBE477DFC299EE
Content-type: multipart/alternative;
Boundary="1__=09BBE477DFC299EE8f9e8a93df938690918c09BBE477DFC299EE"
--1__=09BBE477DFC299EE8f9e8a93df938690918c09BBE477DFC299EE
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: base64
You need to do analysis of the the read/write ratio before worrying about
either the read or write cache rate. If the buff-read:buff-write ratio is
somthing like 1:1, then it would make sense to try to improve the write
cache rate. If it is more like 20:1, then focus on the read cache rate.
A couple of things to consider. If LRU MIN/MAX is set really low (i.e.
0/1), then every buffer write will trigger a physical write. And as soon
as the page is written, it is no longer dirty, and thus can become a
candidate for reuse. If the page is reused, it will obviously have to be
read again before being updated, and would thus cause the write cache rate
to drop.
Perhaps there are queries doing sequential scans on the 'bad' system that
is causing the buffers to be flushed. Maybe checking the output of onstat
-b would give a bit of insite as to how the buffer pool was being utilized.
If on the bad system, sequential scans were occuring, well - that would
explain the increased sar IO count.
M.P.
"Dejan
Stojcevski"
<dejan.stojcevski To
@cosmofon.com.mk> Madison Pruet/Dallas/IBM@IBMUS
cc
08/02/2004 09:35 <forum.subscriber@iiug.org>,
AM <ids@iiug.org>
Subject
RE: IDS performance [3304]
The reason why am I asking this is because we had a problems with the disks
on this machine. From the sar -d output I can see VERY high number of avque
for disks (>5000!).
We are investigating these problems. After some investigation (and
replacements) I get in sar -d decent numbers for avque on disks (0.5). But
the 60% of IDS write cache from onstat -p stays!So the question was is it
related somehow to these hardware problems? On other machines i have decent
number of >92% for this issue. These machines are housing the same IDS
which is doing the same job (same number of transactions, same number of
concurent users and so on). The hardware on these machines are the same and
the sar -d gives me the decent results on these machines. Thanks in
advance.
Dejan.
-----Original Message-----
From: Madison Pruet [mailto:mpruet@us.ibm.com]
Sent: пон 02.08.2004 00:51
To: Dejan Stojcevski
Cc: forum.subscriber@iiug.org; ids@iiug.org
Subject: Re: IDS performance [3304]
I wouldn't worry about the write cache rate as much as the read cache
rate. The write cache rate is highly dependent on what the
application is doing, the size of the rows, and how often updates are
actually occuring. For example, if the row is large enough so that
only one row can be written per page, then your write cache rate is
going to be very low.
Inactive hide details for "DEJAN STOJC...."
<dejan.stojcevski@cosmofon.com.mk>"DEJAN STOJC...."
<dejan.stojcevski@cosmofon.com.mk>
"DEJAN
STOJC...."
<dejan.stojcev
ski@cosmofon.c
om.mk> To
Sent by:
forum.subscrib ids@iiug.org
er@iiug.org
cc
08/01/2004
11:32 AM Subject
IDS performance
[3304]
Do not
quite agree with Madison.
There are applications (like batch jobs or table cleaning)
for which write caching is very significant.
For these applications, one should never set LRU_MAX_DIRTY
and LRU_MIN_DIRTY to less then 2 and 1 respectively.
Never set it to 0 / 0 or 1 / 0 !!!
------------------------------------------
Alexey Sonkin
> From: Madison Pruet [mailto:mpruet@us.ibm.com]
> I wouldn't worry about the write cache rate as much as the read cache
rate.
> The write cache rate is highly dependent on what the application is doing,
> the size of the rows, and how often updates are actually occuring. For
> example, if the row is large enough so that only one row can be written
per
> page, then your write cache rate is going to be very low.
>
> From: DEJAN STOJC.... [mailto:dejan.stojcevski@cosmofon.com.mk]
>
>> Hi to all,
>> A short question: from the output of the onstat -p for the Êched writes I
>> have 69,9%. I beleave this is very bad! What this number should be to
have
>> a good performance ? (>90%?). What might be a problem for such a low
>> performance?
>> On other machines I have at least 94%! Please comment on this number and
>> what it means! Is IDS performing ok with this number beeing so low?
>? Dejan.
--0__=09BBE477DFFEE41D8f9e8a93df938690918c09BBE477DFFEE41D
Content-type: multipart/alternative;
Boundary="1__=09BBE477DFFEE41D8f9e8a93df938690918c09BBE477DFFEE41D"
--1__=09BBE477DFFEE41D8f9e8a93df938690918c09BBE477DFFEE41D
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
Alexey,
I think that you may have misunderstood my point. A lot of folks are
trying to decrease the checkpoint time and are setting the LRU MIN/MAX =
in
an attempt to do that. However, that will mean that as soon as a page =
is
marked dirty, that it will be flushed. If the flushing is combined wit=
h
table scans, then it is very doubtful that the page will remain in the
cache long enough to be reused.
I don't know what the environment is, but I would suspect that it is
possible that they set the LRU MIN/MAX to zero, which would cause a
significant increase in physical IO. I am not recommending that it be =
set
to zero. Quite the opposite.
I fully agree that for batch work and table cleaning that write caching=
is
important --- if there are multiple rows per page. That is why in a lat=
er
email, I mentioned that the key thing to consider was what the buffer r=
ead
to buffer write ratio was. Without knowing the normal usage of the mach=
ine,
it is impossible to determine if a low cache write rate is significant.=
=
Alexey Sonkin =
<alexeis@grandvir =
tual.com> =
To
Madison Pruet/Dallas/IBM@IBMUS, =
08/02/2004 02:27 ids@iiug.org =
PM =
cc
"'DEJAN STOJC....'" =
<dejan.stojcevski@cosmofon.com.m=
k>
Subj=
ect
RE: IDS performance [3307] =
=
=
=
=
=
=
Do not quite agree with Madison.
There are applications (like batch jobs or table cleaning)
for which write caching is very significant.
For these applications, one should never set LRU_MAX_DIRTY
and LRU_MIN_DIRTY to less then 2 and 1 respectively.
Never set it to 0 / 0 or 1 / 0 !!!
------------------------------------------
Alexey Sonkin
> From: Madison Pruet [mailto:mpruet@us.ibm.com]
> I wouldn't worry about the write cache rate as much as the read cache=
rate.
> The write cache rate is highly dependent on what the application is
doing,
> the size of the rows, and how often updates are actually occuring. F=
or
> example, if the row is large enough so that only one row can be writt=
en
per
> page, then your write cache rate is going to be very low.
>
> From: DEJAN STOJC.... [mailto:dejan.stojcevski@cosmofon.com.mk]
>
>> Hi to all,
>> A short question: from the output of the onstat -p for the =CAched w=
rites
I
>> have 69,9%. I beleave this is very bad! What this number should be t=
o
have
>> a good performance ? (>90%?). What might be a problem for such a low=
>> performance?
>> On other machines I have at least 94%! Please comment on this number=
and
>> what it means! Is IDS performing ok with this number beeing so low?
>? Dejan.
=
--1__=09BBE477DFFEE41D8f9e8a93df938690918c09BBE477DFFEE41D
Content-type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable
<html><body>
<p>Alexey,<br>
<br>
I think that you may have misunderstood my point. A lot of folks are t=
rying to decrease the checkpoint time and are setting the LRU MIN/MAX i=
n an attempt to do that. However, that will mean that as soon as a pag=
e is marked dirty, that it will be flushed. If the flushing is combine=
d with table scans, then it is very doubtful that the page will remain =
in the cache long enough to be reused.<br>
<br>
I don't know what the environment is, but I would suspect that it is po=
ssible that they set the LRU MIN/MAX to zero, which would cause a signi=
ficant increase in physical IO. I am not recommending that it be set t=
o zero. Quite the opposite. <br>
<br>
I fully agree that for batch work and table cleaning that write caching=
is important --- if there are multiple rows per page. That is why in a=
later email, I mentioned that the key thing to consider was what the b=
uffer read to buffer write ratio was. Without knowing the normal usage =
of the machine, it is impossible to determine if a low cache write rate=
is significant.<br>
<br>
<br>
<img src=3D"cid:10__=3D09BBE477DFFEE41D8f9e8a93df938@us.ibm.com" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for Alexey Sonkin <a=
lexeis@grandvirtual.com>">Alexey Sonkin <alexeis@grandvirtual.com=
><br>
<br>
<br>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">=
<tr valign=3D"top"><td style=3D"background-image:url(cid:20__=3D09BBE47=
7DFFEE41D8f9e8a93df938@us.ibm.com); background-repeat: no-repeat; " wid=
th=3D"40%">
<ul>
<ul>
<ul>
<ul><b><font size=3D"2">Alexey Sonkin <alexeis@grandvirtual.com><=
/font></b><font size=3D"2"> </font>
<p><font size=3D"2">08/02/2004 02:27 PM</font></ul>
</ul>
</ul>
</ul>
</td><td width=3D"60%">
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">=
<tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3=
0__=3D09BBE477DFFEE41D8f9e8a93df938@us.ibm.com" border=3D"0" height=3D"=
1" width=3D"58" alt=3D""><br>
<div align=3D"right"><font size=3D"2">To</font></div></td><td width=3D"=
100%"><img src=3D"cid:30__=3D09BBE477DFFEE41D8f9e8a93df938@us.ibm.com" =
border=3D"0" height=3D"1" width=3D"1" alt=3D""><br>
<font size=3D"2">Madison Pruet/Dallas/IBM@IBMUS, ids@iiug.org</font></t=
d></tr>
<tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3=
0__=3D09BBE477DFFEE41D8f9e8a93df938@us.ibm.com" border=3D"0" height=3D"=
1" width=3D"58" alt=3D""><br>
<div align=3D"right"><font size=3D"2">cc</font></div></td><td width=3D"=
100%"><img src=3D"cid:30__=3D09BBE477DFFEE41D8f9e8a93df938@us.ibm.com" =
border=3D"0" height=3D"1" width=3D"1" alt=3D""><br>
<font size=3D"2">"'DEJAN STOJC....'" <dejan.stojcevski@cos=
mofon.com.mk></font></td></tr>
<tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3=
0__=3D09BBE477DFFEE41D8f9e8a93df938@us.ibm.com" border=3D"0" height=3D"=
1" width=3D"58" alt=3D""><br>
<div align=3D"right"><font size=3D"2">Subject</font></div></td><td widt=
h=3D"100%"><img src=3D"cid:30__=3D09BBE477DFFEE41D8f9e8a93df938@us.ibm.=
com" border=3D"0" height=3D"1" width=3D"1" alt=3D""><br>
<font size=3D"2@@DQ@
Madison Pruet wrote > > You need to do analysis of the the read/write ratio before worrying about either the read or write cache rate. If the buff-read:buff-write ratio is somthing like 1:1, then it would make sense to try to improve the write cache rate. If it is more like 20:1, then focus on t ..snip I think he has been replicated ! The one and only Colin Bull ________________________________________________________________________ This email has been scanned for all known viruses by the MessageLabs Email Security System. ________________________________________________________________________