Received the below reply from Alan Rollow. Thanks. He says, and
observations show this too, that large average write times due to periodic
syncs of a dirty cache don't necessarily slow down reads.
OPERATIONS BLOCKS AVG TIME(ms)
TYP NAME READ WRITE READ WRITE READ WRITE
vol newspool 31141226 28051270 471444624 455973046 18.9 516.9
However, the i/o system isn't fast enough to keep up with the news feed.
About 2/3 of the feed is being dropped. It's true that the design of innd
is not great with the way it relies on the file system as a database
manager. There are lots of little writes all over the disk.
What would be faster than the existing 2 x KZPAA + integrated controller and
7 x RZ29 stripe set? At least 2x i/o improvement is needed.
Would KZPSA + RZ29W stripe set, or HSZ50 with a big cache + RZ29 array, or
KZPAC + RZ29W show significant gains? Is there another, faster
combination?
Memory (512mb) and processor (2x5/250) do not appear to be bottlenecks.
John Nebel
(Alan's reply)
I think the higher write time on a sync, simply indicates that
you have lots of dirty data in the cache at that point. With
the large, dirty cache you're seeing lots of data trying to
go to the disks at once. That probably raises the average
write time. As long as the reads (that have to touch disk)
are decently fast, how long writes take doesn't matter too
much. That's one of the nice things about the cache. The
writes will go eventually (short of a system crash or power
failure) so reads can take priority. The problem with the
burst of writes is that it may lock out reading for a short
time, which increases response time.
You need to look at the data and request rates of the disks
(iostat or monitor) and see if they're saturated during the
writes. If not, then I wouldn't worry too much about it. If
the disks are saturated during the writes you may want to find
a way to spread them out more. It may be enough to reduce the
amount of memory available to the cache, or put a limit on
the amount of dirty data that can be in the cache. The first
is fairly easy by lowering ubc-max-percent (I think that's it).
The 2nd I'm not sure about.
Received on Mon Dec 29 1997 - 17:37:16 NZDT