Help

● Satisfactory latency or response time is depends heavily on the application's requirements.
● It is not possible to give recommended values for front-end latency since it depends heavily on back-end latency.
● In general, read or write latency values under 10msec are good, and greater than 100msec is usually cause for concern.
Different volumes may have different thresholds for what is acceptable.
● Metro node Local processing overhead on read misses and on write operations is roughly 1msec.
● Metro node Metro systems depend heavily on the performance of the inter-cluster WAN link.
● Be aware of large spikes in latency, which might correlate to front-end or back-end aborts, or to a large front-end queue
depth.
● Understand what is normal latency for your environment, and then you will have a better idea of what is abnormal.
Corrective actions
● Check CPU Utilization chart. If it is extremely busy, the time for metro node to respond to I/O will increase.
● Check back-end latency. If on average the back-end latency is large, or there are large spikes, there could be a poorly
performing back-end fabric or an unhealthy, non-optimized, or over-loaded storage array.
● Perform a back-end fabric analysis, and a performance analysis of the storage array(s) that hosts the underlying storage
volume(s) for the virtual volume.
● Check front-end aborts. Their presence indicate that metro node is taking too long to respond to the host. These might
indicate problems with the front-end fabric.
● Check back-end errors. If metro node back-end is required to retry an operation because it failed, then this will add to the
delay in completing the operation to the host.
● Check front-end operations count (queue depth). If this counter is large, this may explain larger than normal front-end
latency.
● Check for high metro node write delta time. Refer to the Corrective actions section in the Write Latency Delta chart topic.
● Understand the differences in average I/O Size of host requests. Large block requests (> 1MB) will take longer to complete,
whereas small block requests (1KB-8KB) will be faster.
Changing the view
To view the latency of a single director in your metro node system, select the director name from the Director drop-down.
Virtual Volume Latency chart
1. From the GUI main menu, click Performance.
2. Click the + button, and then Add Virtual Volumes Dashboard.
Virtual Volume Bandwidth chart
The Virtual Volume Bandwidth chart provides a time-based view of the total bandwidth (or KB/s or MB/s) in reads and
writes for a virtual-volume. Generally bandwidth (also referred to as KB/s or MB/s), is associated with large block I/O (64KB or
greater I/O requests).
Guidelines
● The desired level of bandwidth performance depends heavily on the host applications and their requested load. Therefore, it
is not possible to provide a threshold of good or bad bandwidth performance.
● Metro node front-end performance depends heavily on the available back-end storage array performance, and in metro node
Metro configurations, the WAN performance for distributed devices.
● There is no absolute recommendation on what is good or bad for IOPS and KB/s. It is typically what the application requests
of the volume.
● If values for these metrics are unsatisfactory, be aware of resource bottlenecks.
● Any running distributed rebuilds or data migrations might negatively affect available host bandwidth.
● Since the metro node Local and Metro implement write through caching, a small amount of write latency overhead (typically
<1msec) is expected. This latency may affect applications that serialize their I/O and do not take advantage of multiple
outstanding operations. These types of applications may see a throughput and IOPS drop with metro node in the data path.
52
Monitoring the system