Analyzing Sun StorEdge[TM] 6920 Performance Issues

Asset ID:	1-75-1006883.1
Update Date:	2011-01-12
Keywords:

Solution Type Troubleshooting Sure

Solution 1006883.1 : Analyzing Sun StorEdge[TM] 6920 Performance Issues

Applies to:

Sun Storage 6920 System
All Platforms

Purpose

This document attempts to address potential performance problems with the Sun StorEdge[TM] 6920 array, based on the set of symptoms below.

Symptoms:

Bad/Slow Performance
Bad/Slow Database Performance
Bad/Slow Test or Benchmark Performance
Expectation of array performance
Location of Sun's Best Practices for performance of the array

Last Review Date

January 12, 2011

Instructions for the Reader

A Troubleshooting Guide is provided to assist in debugging a specific issue. When possible, diagnostic tools are included in the document to assist in troubleshooting.

Troubleshooting Details

A. Location of Best Practices

The general best practice guide for the 6920 can be found at:
http://download.oracle.com/docs/cd/E19224-01/819-0122-10/819-0122-10.pdf

If you are require additional troubleshooting or need help beyond these general guidelines, please continue to Step B.

B. Location of Benchmark Statistics

Oracle maintains a relationship with the Storage Performance Council(SPC). The
6920 Array has been benchmarked against the SPC-1 benchmarking standard. The
data for this benchmark is located here:
http://www.storageperformance.org/results/a00033_sun_SPC1_executive-summary_a.pdf

This is an independent organization that Oracle submits our storage platforms
to for a benchmark. The actual benchmark configuration is explained at:
http://www.storageperformance.org

If you require additional troubleshooting or need help beyond the benchmark
statistics, continue to Step C

C. Determine What is NOT Performing well

Document for yourself, the answers to following questionnaire:

What command, utility, application, or user action is running slow?
What operating system(Solaris, Windows, AIX, Linux, etc) is running the above?
Indicate how many host systems are impacted, what the hostnames are, and what operating systems are on each.
Has the above always behaved slow? If not, when was it running as expected?
Is the above action part of a larger, overall application? If so, what application?
Does the command, utility, application, or user action run on a filesystem? If so, list them.
Please list the devices on the 6920 are the source and/or target of this action.
Do you use any of the Data Services on the 6920(Snapshot, Mirror, Remote Replication)? If so, which ones?
If possible, please identify what your performance expectations are with regards to your application, and separately with regards to your 6920 array.

Continue to Step D.

D. Verify Hardware Status

Our studies have shown that 80-90% of all performance issues are caused by
hardware issues. Refer to <Document: 1012833.1> : Analyzing Sun StorEdge 6920 Component Failure Alarms, Notifications, and LEDs. If
you find no hardware faults, please continue to Step E.

E: Firmware Review

7-15% of all Performance issues are the result of a code flaw fixed in new
software and/or firmware. Start by reviewing the current revision of array
code. This can be done by either:

Log Into your array https://:6789.
Click on the Storage Diagnostic Environment Link.
Click on the Inventory Tab.
Click on the Service Processor link under the component column of the Inventory table.
Review the version.

By collecting a 6920 Solution Extract, and reviewing the /Rack/etc_release'' file. Refer to <Document: 1003756.1> : Collecting an Extractor for a Sun StorEdge[TM] 6920

The following table represents critical performance related bug fixes
sorted by each release. If you are below a release found in this table,
consider upgrading your array. For upgrades of the array, refer <Document: 1002638.1> Preparing for Sun StorEdge[TM] 6920 Upgrades.

Bug ID	Summary	Fix in Release	Notes
6309119	DspPersistence.xml leak leads to performance issues.	3.0.1.13
6366175	A T4 visible on FC but not servicing R/W cmds causes I/O failures (path takes too long to go down)	3.0.1.22
6359654	T4 PG hangs after a single drive failure and Inter-Controller communication error condition	3.0.1.22
6383247	Storade request the glist info in fruprop.htm page impacts IO performance every 10 minute	3.0.1.22
6388362	RM: Further optimizations to bitmap I/O algorithms	3.0.1.22	For Remote Mirroring Configurations
6391726	RM: host IO during a resync on an async set should be treated asynchronously	3.0.1.22	For Remote Mirroring Configurations
6237676	LM: Make volume quiesce faster by adding adding a VSM priority queue (needed for failovers)	3.0.0.26	Mirroring Configurations
6439969	LM: SNAP: Creating a 4 component LM with 800% Snap reserve is consistently crashing BV	3.0.1.26	Mirror and Snapshot Configurations
6481445	Copy Recon not properly transitioned to Parity Recon after 2nd error (causes poor Recon performance)	3.0.1.26
6214420	Throttle Frequency of PIT Rollback Progress Reports to MIC to < 1 every 2 seconds	3.0.0.26	For Snapshot configurations
6332241	RM: improve sequence number comparison code	3.0.2.38	For Remote Mirroring configurations
6383750	Poor performance on single threaded large host IO's	3.0.2.38
6337662	RM: Need Buffer Credit changes to reduce replication link starvation on slow interfaces	3.2.0.38	For Remote Mirroring Configurations
6250864	FCD: Improper aborted commands due to ISP handling of TMFs (results in unnecessary host retries)	3.2.0.38

If there are no bugs that match your configuration and/or firmware revision,
continue to Step F.

F. Basic Data Collection

Please collect the following data:

Answers to the Questionnaire in Step C
Array Solution Extract(Refer to : How to collect an extractor from a Sun StorEdge[TM] 6920 (2.x and 3.x))
Solaris Explorer Collection
Non-Solaris data collection
Any alarms or LEDs that were not resolved by actions taken in : Analyzing Sun StorEdge 6920 Component Failure Alarms, Notifications, and LEDs

and contact Oracle

Attachments

This solution has no attachment