I am pretty sure netapp took on the role of performance consultant on their own accord when they made the decision not to allow us stupid customers to use perfstat viewer ourselves.
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Jeff Mohler Sent: Friday, September 13, 2013 4:23 PM To: Steiner, Jeffrey Cc: Toasters@teaparty.net Subject: Re: high CP_reads/writes ratio
Or, just reallocate all volumes in the affected aggregate and save two weeks of hassle expecting support to suddenly become performance consultants.
To then be told to reallocate the volumes in the affected aggregate.
*popcorn*
IMHO, it's quarterly preventative maintenance on a netapp.
Sent from my iPhone
On Sep 13, 2013, at 3:07 PM, "Steiner, Jeffrey" <Jeffrey.Steiner@netapp.commailto:Jeffrey.Steiner@netapp.com> wrote: Aha, that changes things. A standby database is an especially demanding series of alternating reads and writes. I think your best bet is probably a support case to ask them to identify the bottleneck. A couple hours of perfstat at 10 minute intervals should cover it, but you’ll have to see what they say for sure. It should be pretty easy to identify the exact reason for the limitation, given the use of DataGuard.
From: Fred Grieco [mailto:fredgrieco@yahoo.com] Sent: Friday, September 13, 2013 8:58 PM To: Steiner, Jeffrey; Toasters@teaparty.netmailto:Toasters@teaparty.net Subject: Re: high CP_reads/writes ratio
I'll check with the DBAs on that.
I'm looking at the replication target filer and it's actually even worse, with cp_reads almost matching user_writes on the physical disks. The replication method is dataguard.
________________________________ From: "Steiner, Jeffrey" <Jeffrey.Steiner@netapp.commailto:Jeffrey.Steiner@netapp.com> To: Fred Grieco <fredgrieco@yahoo.commailto:fredgrieco@yahoo.com>; "Toasters@teaparty.netmailto:Toasters@teaparty.net" <Toasters@teaparty.netmailto:Toasters@teaparty.net> Sent: Friday, September 13, 2013 2:21 PM Subject: RE: high CP_reads/writes ratio
That sounds strange. An aligned Oracle database ought to be doing whole block writes under all circumstances, with the exception of a tiny amount of CP read behavior with the archive and redo logs. You can occasionally get into trouble with SAN filesystems where the block size of the filesystem itself results in misalignment, but not here.
Can you share the load average and top 5 wait events section of a one-hour AWR report encompassing this 15 minute cycle so we have an idea what kind of IO is occuring and the latencies you are experiencing?
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Fred Grieco Sent: Friday, September 13, 2013 8:07 PM To: Toasters@teaparty.netmailto:Toasters@teaparty.net Subject: high CP_reads/writes ratio
What kinds of things can cause a high CP_reads/writes ratio? And what can I do about it?
I have an Oracle system with ASM that doing writes in a 15 minute cycle, and it causes a lot of writes with CP reads. The oracle ASM luns are basically the only thing on the aggregate. Disk alignment is fine (which is the first thing I thought of). I've attached a screenshot of the Oncommand graph for one of the disks in this aggr-- not sure if that will come through.
The filer is a 3220 with 8.1.2 7-mode. Fibre channel attach, and there are about 20 luns under two volumes.
TIA,
Fred
<image001.jpg>
_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters