Overview
Troubleshooting performance on a DXi7500 can be complex and very time consuming. This methodology provides a standard set of tools and methods to significantly decrease the amount of time required to resolve DXi7500 performance related SRs.
Gather Collect Logs and DART Data
-
Gather collect logs. (For details about DXi Log Reading, refer to the DXi Log Reading Basics topic.)
- Make sure that the collect has a name of collect*.zip or dxi7500collect*.zip
- Upload collect to anywhere in incoming on gps.quantum.com as anonymous or in the following locations on raptor:
- /stornext/snfs1/ticketinfo/SRx*
- /stornext/snfs1/ticketinfo/ASPS/*
- /stornext/snfs1/ticketinfo/incoming/*
- Collect logs will be scanned and imported to susrepo automatically. Could take up to 15 minutes for import to show on the susrepo page
-
Gather DART/dbexport, and then upload export as anonymous to gps.quantum.com in incoming/DART.
Analyze the DXi Using DART Data
- Identify a Timeline
- Analyze Garbage Collection: If GC cannot “keep up” during normal operation then the customer needs additional DXi system/s. This is excluding things outside of “normal operation” such as deleting a large amount of data, excessive bplabel jobs or a backup retention policy change.
- Analyze Ingest and Reads: 6 TB of ingest per day is considered the maxium ingest rate that the DXi7500 can handle without causing significant performance problems. This is compounded when performing concurrent reads.
- Analyze Capacity: The DXi7500 is considered full when the blockpool size is 80% of Total Capacity. ( Full in this context is not referring to 100% capacity ) DXi7500 systems are sold with this 20% buffer in mind. We typically see performance degradation around 75%-80% blockpool.
- Analyze Reduction Ratio: A Reduction ratio of <5:1 is considered poor and should be investigated
- Analyze Disk I/O: A constant Disk I/O distribution percentage of >70% is considered excessive
What's Next?
1 - Identify a Timeline >
Quantum