Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle Performance -- Possible Disk Bottleneck

Re: Oracle Performance -- Possible Disk Bottleneck

From: <beth.stover_at_gmail.com>
Date: Thu, 07 Jun 2007 12:49:40 -0700
Message-ID: <1181245780.151490.137480@q66g2000hsg.googlegroups.com>


On May 25, 7:42 am, EscVector <J..._at_webthere.com> wrote:
> On May 24, 5:56 pm, beth.sto..._at_gmail.com wrote:
>
>
>
>
>
> > My apologies if this subject has been discussed. I searched the
> > groups, and I couldn't find a good thread.
>
> > We've been having performance problems with our Client/Server
> > application for months. Users contantly complain of slow response
> > times to their queries.
>
> > Here's the environment:
>
> > Oracle 9i on Windows. Poweredge 6850. 4, 3 GHz Quad Core
> > Processors. 8 GB RAM. 9i databses are stored on an EMC Clarrion
> > CX500 LUN -- RAID 10. 6, 15K 146GB dedicated disks. Oracle logs are
> > stored on a separate RAID 10 LUN on dedicated disks. 1 GBE switched
> > backend. Users connect using FastEthernet. XP clients. All disks on
> > the SAN are fibre channel.
>
> > CPU utilization is fine. RAM utilization is fine. Throughput on the
> > NIC is fine -- maxes out at 50 Mbps for a short while when users first
> > log in in the morning. Averages are 20 Mbps.
>
> > Using perfmon in Windows, If I look at Disk Reads/Sec and Disk Writes/
> > sec., here's what I see for averages:
>
> > Disk Reads/sec = 2200 Avg
> > Disk Writes/sec = 10 Avg
>
> > Our reads/sec seem EXTREMELY high for only 80 users.
>
> > Can someone help me understand if this is truly a disk bottleneck?
>
> > Thanks in advance!
>
> Don't use the windows tools to check on SAN performance. Talk with
> the storage admins. They will have a much better perspective on both
> throughput and utilization. The perfmon tool might indicate an issue,
> but I doubt it will tell much. I like the statspack suggestion if
> done accurately and snap are scoped correctly.
>
> Do you have virus software running? This will typically bump up I/O
> reads in perfmon.- Hide quoted text -
>
> - Show quoted text -

Thanks for all of the information and suggestions.

I did some comparison of Windows tools (Perfmon) and EMC tools (Navisphere analyzer). Perfmon was actually reporting the IO correctly. Average IO reads are 2000, Average Write IO is @ 10. There are some interesting metrics that I don't understand from Nav. Analyzer: The storage processors are showing peaks close to 100% at certain times of day, but the disks are not at 100%. I'm not sure what that means. LUN % utilization is the same, so it looks like the Storage processors are responsible for the high % utilization.

STATSPACK analysis shows something similar to Perfmon and Nav. Analyzer: Physical reads are 2552, physical writes are 52. There's a ton of information in the statspack report, so I'm not sure what else to look at.

There is anti-virus software on this machine, but I don't think it accounts for a significant part of the 2000+ IOPs per second. We use the same product on all of our servers. IO is not a problem on any other server. On this machine, there are peaks of 10,000 IOPs. This seems abnormally high.

We're a very small shop, so I'm the storage person. This is a new technology for us, so I'm in a learning curve here.

There don't appear to be many good SAN related groups that are active, so I'm hoping someone here has experience with SANs and ORACLE to help out.

EMC support is NOT what we were expecting. For the amount we pay for support, the response is very very disappointing. I've had a ticket open on this for MONTHS. Literally.

I guess the bottom line here is that I need to prove to my boss that this is a disk bottleneck and that giving the database more spindles will help. Also, I'd like to understand why IO reads are so high for Oracle.

Any information would be appreciated. Received on Thu Jun 07 2007 - 14:49:40 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US