4 - Analyze Capacity (DRAFT)

Overview

This playbook describes how to analyze the capacity levels and determine how they impact performance.

 

 

Analysis

 

Go to the DART repository and locate the serial number for the desired system then click on it.  For this example we’ll use a DXi7500 owned by Harris IT.  We’ll also be using the sample dataset that was determined using the Lifetime Analysis playbook.  When looking at capacity we will use the Capacity Detail view in DART.  The link to this dataset is:

http://dart.quantum.com/cgi-bin/stats?DB=CX0929BVA00446-20110223-123021&pr=2&start=1293080747&end=1298482221&base=1000

This timeline is from 12/23/2010 to 2/23/2011 and we will start with the Data Volume Overview graph above.  From this graph we see that:

  • Total Capacity is 75 TB
  • Blockpool (After Reduction) is 58 TB
  • Blockpool is 67% of total capacity
  • Used Disk Space is under the Truncation start watermark
  • Garbage Collection has been running for 5 weeks
  • Capacity increase is steady

Next we skip down to the Used Disk Space graph.  From this graph we learn:

  • There are several times during weeks 52, 01, 04, 05, 06 and 07 where used disk space went well above the truncation threshold and started throttling. 
  • These colors over the truncation mark mean that the data in cache could not be truncated typically due to a dedup backlog.


Conclusion

From this sample period of the previous 9 weeks we can see that the blockpool has been less than 67% of the total capacity which is not considered to be a capacity problem.  An argument can be made that if there was more disk space that the system wouldn’t hit throttle mode because there would be more space available for non truncated data.  However, this would do nothing to prevent a dedup backlog and the several weeks of GC.

 

From these numbers it would not be wise to recommend a capacity upgrade.  Since GC takes so long to finish and there are such long periods of time with a dedup backlog the recommendation should be to add another DXi or offload some ingest somewhere else.  Adding more capacity in this scenario would more than likely result in revisiting this same problem in the future.

 

Next:  Reduction Ratio

 

Previous: Ingest and Reads

 

 



This page was generated by the BrainKeeper Enterprise Wiki, © 2018