I have a lun which holds the SQL data file and it is showing increased lun latency.
The data is from this month's monthly report for storage, shows LUN latency increasing for the database data file LUNs. Past experience has shown, users become affected at about the 11 ms mark and action should be taken to avoid this scenario. So a NetApp support case was opened to try and address the performance issue.
How do I show if this is a caching or fragmentation issue? I have been looking through the prefstat reports and verything looks healthy apart from the latency. Not sure what "cp_dirty_allocation_blks" is but it is 1000+
Not saying this is definitely the case of fragmentation, but can you check the LUN in question against this issue first?
reallocate measure [-l logfile] [-t threshold] [-i inter_val] [-o] pathname | /vol/volname Start a measure-only reallocation on the LUN, large file or volume. A measure-only reallocation job is similar to a normal reallocation job except that only the check phase is performed. This allows the optimization of the LUN, large file or volume to be tracked over time, or measured ad-hoc.
The threshold when a LUN, file or volume is considered unoptimized enough that a reallocation should be performed is given as a number from 3 (moderately optimized) to 10 (very unoptimized). [...].The default threshold is 4.
Having said that, I've heard stories from people getting fairly low numbers during measurement, yet when they actually run reallocation, their performance vastly improved
Early results are in. Reallocate the lun in the volume does reduce LUN latency for SQL server my 20% in my system! It is still to early to know that the process was a success but early results do look very good.
A total of 7 luns where reallocated on a single 56x 300Gb 15k disk aggregate on a FAS3070
E: 134Gb took 26 min
F: 135Gb took 13 min
G: 100Gb took 26 min
H: 98Gb took 15 min
J: 185Gb took 12 min
K: 100Gb took 37 min - TL
i: 395Gb took 7 min - TL
Did not notice any issues with extra IO or CPU load on the filer during the work. Still waiting to find out how big the snapshots will be.
Hope this post helps you plan your own reallocation work.
Many thanks for posting the results. I reckon many folks will learn a nice lesson based on your experience (that includes some NetApp chaps who, hmm, tend to forget that fragmentation may be an issue )
Re snapshots growing - if they didn't balloon straight after the reallocate run, you are completely safe in my opinion.