Re: troubleshooting slow I/O performance.

From: Chris Stephens <cstephens16_at_gmail.com>
Date: Mon, 07 May 2018 17:40:26 +0000
Message-ID: <CAEFL0syihxQtD1Fnd_fjsUAEB1nOewkKx78omZ2Z735yOwNMOg_at_mail.gmail.com>



8 physical disks / lun.

Fibre Channel

raid 10 with external ASM redundancy.

thanks stefan!

On Mon, May 7, 2018 at 12:12 PM Stefan Knecht <knecht.stefan_at_gmail.com> wrote:

> By path I meant how the storage is connected to the server. Fibre channel,
> iSCSI, etc...
>
> And I assume you mean that you have 30TB LUNs - I don't think there are
> 30TB physical disks. The actual number of physical spinning rusty things is
> the number that's important. E.g. how is your LUN made up?
>
> And of course, it's also important to know how the disks are arranged when
> the LUN is built - RAID 1, RAID 5 (I hope not but that might explain the
> issues you're seeing) RAID 10, etc...
>
> I'd say a friendly chat with the storage guy is probably in order :) It
> could be any number of things - but what's really key to get good
> performance out of bare metal drives is the number of drives you got.
>
>
>
>
>
> On Tue, May 8, 2018 at 12:08 AM, Chris Stephens <cstephens16_at_gmail.com>
> wrote:
>
>> ASM
>> 6 30TB spinning drives
>> type of path? we are not using asmlib or asm_fd (whatever its called).
>>
>>
>> On Mon, May 7, 2018 at 11:54 AM Stefan Knecht <knecht.stefan_at_gmail.com>
>> wrote:
>>
>>> Some details would help:
>>>
>>> - ASM or FS? Type of FS?
>>> - LUNs? Numbers, sizes?
>>> - metal? SSD? Type of path to the disks?
>>>
>>> Etc...
>>>
>>>
>>> On Mon, 7 May 2018, 21:00 Chris Stephens, <cstephens16_at_gmail.com> wrote:
>>>
>>>> We have a new 5 node 12.2 RAC system that is not performing the way we
>>>> want.
>>>>
>>>> The glaring issue is that "db file sequential read"'s are taking ~10ms.
>>>> before i lob this over to the storage administrators, are there any
>>>> possible areas in the clusterware/database configuration that I should
>>>> investigate first? i have root access to all of the nodes. is there any
>>>> information i can collect that would expedite the process of figuring out
>>>> why we have such slow I/O times?
>>>>
>>>> slow i/o was discovered by running slob. if you don't know about that
>>>> tool, you should. we all owe kevin a debt of gratitude. ;)
>>>>
>>>> if nothing else, i hope to learn a little more about storage than i
>>>> currently know (which isn't much).
>>>>
>>>> thanks for any help.
>>>>
>>>> chris
>>>>
>>>>
>
>
> --
> //
> zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
> Visit us at zztat.net | _at_zztat_oracle | fb.me/zztat | zztat.net/blog/
>

--
http://www.freelists.org/webpage/oracle-l
Received on Mon May 07 2018 - 19:40:26 CEST

Original text of this message