I did make some changes to the FAST policy on the Storage groups that has the R2 volumes to have the destage from cache to happen on faster disks, we have had less number of drops since then.
Is write pacing a good solution in my case or should be I thinking of adding more disks at this time ?
The source array is a VMAX400K and the remote array is a VMAX 20K .
Your R2 may be running out of back end disk capability. Check the heatmap. If the drives are overloaded, then destage from cache is slower, leading to overwhelming the WP. You may need to add drives to the R2 side.
there are two types of write pacing. Device-level and Group-level.
group-level write pacing may apply. The documentation description is below but basically, group-level attempts to slow down host I/O rates so they don't overwhelm your rdf link capabilities. This may result in a slower response time to the applicable hosts.
We enabled both (device-level and group-level) in our specific environment, MSCS with SQL server with no noticeable affect in SQL IO performance.
It may help some but ultimately, we increased cache and link bandwidth to resolve our rdf issues.
Group-level write pacing
SRDF/A group-level write pacing detects when the I/O service rates are lower than the host I/O rates, and then takes corrective actions to slow down the host I/O rates to match the SRDF I/O service rates. When activated, this functionality performs write I/O pacing on all devices in the SRDF group during an SRDF/A session. This operation also provides an exemption capability to prevent group-level write I/O pacing on specified devices within a group.
nerdnair
1 Rookie
•
68 Posts
0
June 7th, 2017 11:00
Thanks Mark,
I did make some changes to the FAST policy on the Storage groups that has the R2 volumes to have the destage from cache to happen on faster disks, we have had less number of drops since then.
Is write pacing a good solution in my case or should be I thinking of adding more disks at this time ?
The source array is a VMAX400K and the remote array is a VMAX 20K .
Regards,
Vaishak
mark_rogov
14 Posts
1
June 7th, 2017 11:00
Your R2 may be running out of back end disk capability. Check the heatmap. If the drives are overloaded, then destage from cache is slower, leading to overwhelming the WP. You may need to add drives to the R2 side.
JimK513
1 Rookie
•
89 Posts
0
June 8th, 2017 09:00
there are two types of write pacing. Device-level and Group-level.
group-level write pacing may apply. The documentation description is below but basically, group-level attempts to slow down host I/O rates so they don't overwhelm your rdf link capabilities. This may result in a slower response time to the applicable hosts.
We enabled both (device-level and group-level) in our specific environment, MSCS with SQL server with no noticeable affect in SQL IO performance.
It may help some but ultimately, we increased cache and link bandwidth to resolve our rdf issues.
Group-level write pacing
SRDF/A group-level write pacing detects when the I/O service rates are lower than the host I/O rates, and then takes corrective actions to slow down the host I/O rates to match the SRDF I/O service rates. When activated, this functionality performs write I/O pacing on all devices in the SRDF group during an SRDF/A session. This operation also provides an exemption capability to prevent group-level write I/O pacing on specified devices within a group.