play around with write cache ? In some instances disabling write cache on the LUNs might produced better results than having write cache enabled.

Play around with the watermarks ? I've heard stories of people LOWERING the watermarks and getting better performance.

Ok here is an explanation of what you heard and what we normally doing with all ATA disks drive when the entire clariion exprience performance degradation .

Premise , clariion cache is global , so all the luns share the same cache , if a host write intensive to a lun and the destage of the data from the cache to the spindles is slow due to the type of the disks drive, like ATA drives you may fill up the entire clariion write cache and force the clariion to perform a force flush .
Force flush operation destage all the page in cache to the disks and pause the host i/o , as you can imaging this operation hurt the overall performance .

Force flush occur when we pass the high water mark .

The correct way to understand if you are in this situation is to retrieve a nar files and check the following :

- % dirty pages , if the % of dirty pages is most of the time above the high watermark this mean you force the clariion to perform a force flashing

- Cpu utilization need to be below 70%

- check for any trespass activity

there are 2 different approach we normally use to alleviate this problem :

- the first approach is to decrease the values of high and low watermark . For example if the high and low are set to 80 and 60 , you need to decrease those values to 60 and 40 .

- If you don't worry about performance on the ATA luns you can disable the write cache on the ATA luns .

I will recommend you to open a ticket with the clariion support and submit a set of spcollect with a nar files , there are million of reason why you can exprience a performance degradation . Consult one of the people in the clariion support before apply any change to your configuration .

Also if you fill up the cache probably you not use the right disks drive technology for the type IOPS you want to accomplish and will be better to evaluate to migrate the data to different drive type (SATA,Fiber)

Regards

like ATA drives you may fill up the entire clariion write cache and force the clariion to perform a force flush .

Interesting. So disabling the write cache on the SATA LUNs could sidestep the problem entirely?

I have SP collects and NAR files from this unit. Is there a tool or a method that I can use to analyze them?

Thanks.. We have not licensed analyzer. We have a month-long support case open with zero result, other than the replacement of a disk with a few soft errors. I don't know how to get them to stop asking for host grabs, logs, SP collects, and NAR's again and again and start actually analyzing performance for us.

If you have the license you can use navisphere analyzer and see the % of dirty cache you have but as I said before I will reccomend to involve the clariion support before arrive at any conclusion .
Regards
Pierluca

Please send me the service request number I will see what can I do for you .
I'm not in the support but I will try my best for help you .
I think if you not get an aswer from the support you shuld contact your sales rep or the local cs manager.

Thanks
Pierluca

This is interesting.

I'm using SQLIO running in a VM as a quick go/no-go test. Yes, I know it's not very accurate.

Turning off write-cache made put the SQLIO numbers in the toilet regardless of what the LUN was doing. Turning off the read-cache (with write-cache on) hurt IOP's by 40% when the LUN is quiet but it boosted the IOP's when heavy writes were occurring (via cloning a VM) by a factor of 5. Ok, this is somewhat better.

The truly impressive results happen when I turn ON all caching then turn OFF prefetch! I get IOPS of about 50% of our tier 1 FC LUN's when quiet and about 35% when busy. This is what I'd expect from cheap SATA!

After about five minutes of letting that VM clone operation run, it all falls apart. I think the cache high-watermark is being hit and a forced flush is occurring (as described above). Still, this is WAY better.

I'm amazed that our SP's only have 3GB of cache. Is that normal?

Yes. The Cx500 was the mid-level model of the CLARiiONs from two generations ago. The mid-level model of the next generation, the Cx3-40, had 8GB of cache.

Richard ,

Using sql io is not good for the type of the disks you have .
SATA /ATA disks are good for large block i/o single streaming applications , like backup .
SQL i/o is random 4kb .

For testing your ATA disks you need to try to run a single stream test write with at least 64K io size .

Regards
Pierluca