Re: troubleshooting slow I/O performance.

From: Chris Stephens <cstephens16_at_gmail.com>
Date: Wed, 09 May 2018 13:48:32 +0000
Message-ID: <CAEFL0sw4YDeS5h55bXN7Vu9iNhtUGwQG1_0C7GZ=fX9rsN0G5w_at_mail.gmail.com>



thanks for everyone's input on this. the 10ms I/O times are relatively constant on this disk group. we were just looking to make sure those disks are performing as expected. I have always considered 5ms single block I/O response times for spinning disks as typical and when I saw 10ms I thought maybe something was up. not sure how i got that 5ms number stuck in my head.

Luckily we also have a disk group on SSD's that performs far better.

thanks again everyone. even you and your criticisms mladen. :)

On Wed, May 9, 2018 at 2:43 AM Stefan Koehler <contact_at_soocs.de> wrote:

> Hello Mladen,
> sure I agree if you already know that the disks are the bottleneck (too
> slow) but in this case the OP does not know and want to identify /
> drill-down to the bottleneck.
>
> Let's summarize the provided information quickly:
> - 5 node 12.2 RAC system
> - "db file sequential read"'s are taking ~10ms
> - ASM (external redundancy)
> - 6 x 30TB spinning drives / 8 LUNs via FC
>
> First of all we don't know how the 10 ms (I guess/assume average) are
> formed. Are most of the IOs in this latency bucket or is the majority of IO
> much faster and the OP just got a few very bad outliers that lead to this
> average.
>
> Secondly he is using RAC and so also some kind of shared storage - even
> typical mid-range storage for such environments got read/write caches which
> improve the response time of spinning disks drastically. We just don't know
> how it looks like and it seems like the OP does not either.
>
> IMHO it is better to give the OP a way to figure it out on his own (and
> blktrace is a good tool to do that) instead of wild guessing and already
> stating that the root cause of his observation is the "slow" spinning disks.
>
> P.S.: In the past I was able to fix several IO outlier problems with
> blktrace by the way ;-)
>
> Best Regards
> Stefan Koehler
>
> Independent Oracle performance consultant and researcher
> Website: http://www.soocs.de
> Twitter: _at_OracleSK
>
> > Mladen Gogala hat am 9. Mai 2018 um 05:14 geschrieben:
> >
> > There is rarely need to lose time by doing blktrace. If disks are too
> > slow, the ONLY real answer are faster disks. I used to play with IO
> > elevators, read ahead, systemtap and stuff like that, but the truth is
> > that whenever I delved into that stuff, nothing useful ever came out of
> > it. When IO is too slow, the faster disks are the only solution. No
> > amount of tuning will turn a Ford Taurus into a Ferrari. Storage
> > configuration is usually planned ahead of configuring the database. It
> > may even be prudent, I apologize for using harsh language, to do some
> > testing ahead of building the whole cluster. This sounds like the
> > configuration done by the most interesting DBA in the world: the one who
> > doesn't test his stuff often, but when he does so, he does it in
> production.
> >
> > --
> > Mladen Gogala
> > Database Consultant
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed May 09 2018 - 15:48:32 CEST

Original text of this message