I've asked a dba to look at your questions/comments.
I'm looking at a blog post http://recoverymonkey.org/2014/09/18/when-competitors-try-too-hard-and-miss-...
It discusses how to read a STATIT for sequential I/O size. I have a statit listing . . .
disk ut% xfers ureads--chain-usecs writes--chain-usecs cpreads-chain-usecs greads--chain-usecs gwrites-chain-usecs /aggrfcp/plex0/rg0: 0b.01.0 54 107.88 0.00 2.11 2211 1.00 34.35 214 1.91 13.48 276 104.97 64.00 188 0.00 .... . 0b.01.1 55 107.96 0.00 2.11 1684 1.13 30.56 216 1.86 12.90 347 104.97 64.00 192 0.00 .... . 0b.01.10 56 111.70 4.14 4.76 1852 0.98 29.22 258 1.61 6.35 750 104.97 64.00 195 0.00 .... . 0b.01.2 56 110.67 4.07 4.72 1814 0.65 43.40 192 0.98 9.70 565 104.97 64.00 200 0.00 .... . 0b.01.3 56 110.75 4.16 4.72 1856 0.66 43.15 199 0.97 10.01 517 104.97 64.00 201 0.00 .... . 0b.01.4 57 110.85 4.23 4.71 1751 0.65 42.99 194 1.00 9.96 517 104.97 64.00 206 0.00 .... . 0b.01.5 57 110.62 4.06 4.97 1770 0.65 43.42 194 0.94 10.15 522 104.97 64.00 210 0.00 .... . 0b.01.6 57 110.63 4.05 4.82 1764 0.65 43.55 197 0.96 9.83 562 104.97 64.00 210 0.00 .... . 0b.01.7 57 110.73 4.12 4.61 1853 0.66 43.27 196 0.98 9.13 603 104.97 64.00 217 0.00 .... . 0b.01.8 57 110.74 4.16 4.72 1844 0.65 43.54 197 0.95 9.18 583 104.97 64.00 218 0.00 .... . 0b.01.9 57 110.75 4.16 4.76 1819 0.65 43.06 207 0.97 9.13 560 104.97 64.00 223 0.00 .... .
This looks like it's doing sequential reads in 4k I/O's. I have multiple of these listings and they are all the same.
rick
From: Steiner, Jeffrey [mailto:Jeffrey.Steiner@netapp.com] Sent: Wednesday, June 29, 2016 11:33 AM To: Rhodes, Richard L. rrhodes@firstenergycorp.com; toasters@teaparty.net Subject: RE: OnTap read block size?
Is this NFS or FC?
By default, Oracle does sequential reads in 1M chunks. If they have a 16k block size on the database, it should be reading in units of 64, not 128. Also, just because Oracle tries to read 1MB chunks doesn't mean the database can do that.
They really shouldn't be using cio as a mount option either. Any remotely current version of Oracle will mount the datafiles with concurrent IO so long as they have filesystemio_options=setall, which is also what they should have.
If you can send me a sample report from 'awrrpt.sql' of no more than one hour elapsed time from a period where they are unhappy with performance, I will take a look and what's going on. I can say with 100% certainty that if they really are doing multiblock reads with 16K units the problem isn't ONTAP. I suppose it could be a 16K block size on a badly fragmented jfs2 filesystem, but I really doubt it. I think something is being misinterpreted.
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rhodes, Richard L. Sent: Wednesday, June 29, 2016 4:36 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: OnTap read block size?
OnTap 8.1.2p1
Our DBA's are complaining that our nSeries (N3220/FAS2240) is reading really slow due to it only returning small 16k blocks. The DBA's are saying the Oracle multi-block read ahead should be reading 128 x 16k blocks = 2m read, but it's only seems to be reading/returning 16k at a time.
On a AIX filesystem mounted CIO, if I run "dd if=/dev/zero of=z bs=1m count=9999" I see writes of 500k.
In the same filesystem mounted CIO, if I read an existing db file "dd if=<dbfile> of=/dev/null bs=1m" I see reads of up to 30k.
Q) Is there a limit in OnTap on read size?
Thanks
Rick
________________________________ ________________________________
The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
----------------------------------------- The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.