Unsolved
This post is more than 5 years old
27 Posts
0
1194
March 15th, 2012 12:00
What are the primary reasons for SRDF/A cycle getting elongated
For few of my RDFGs , the SDRF/A cycle is getting elongated ( sometimes to 320 s ) and intermittently causing those groups to drop.
What can be the primary reasons for the cycles to get elongated ?
The RDF is between two DMX-4 @ 5773.
No Events found!
rajshekhar1
30 Posts
0
March 15th, 2012 13:00
The SRDF drop can be caused due to number of issues:-
Some questions that needs to be answered are:-
1)Are the RDFG groups that are dropping using same RA pairs?
2) Are DSE pools configured on the array?
3) Has anything changed with RDF Bandwidth? or More devices configured to use SRDF/A? Link Loss?
4) Any workload changes that might affect cache utlization
5) Is there a pattern that you see for SRDF drops? like a particular time of day, etc
Use sysmstat to continously monitor the cycle time to see what you see.
debmdig
27 Posts
0
March 16th, 2012 00:00
Raj,
My answers are below:
1. Yes i see only 3 RDFGs dropping intermittently
2. No spillover configured for the array
3. No changes in B/W but some new devices was added to the replication someday back.
4. Cache slots usage remains fluctuating
5. Yes there is a pattern, the cycle time goes extremely high at only a particular time and the device WPL is reached , causing the RDF to drop.
We have Performance Manager ( and also some custom scripts that i deployed ; incorporating symstat ) to monitor the cycle time and i can see the pattern for more than a week now.
rajshekhar1
30 Posts
1
March 16th, 2012 06:00
If you do not have SRDF Priority control setup we can narrow down the problem to the 3 RDFG groups.
I would look into devices in the 3 RDFG groups to see if some devices are doing too many writes during the interval.
As you are saying that there is a pattern , there might be host writes taking place at the time causing device WPL .
If you cannot find devices in the RDFG groups matching the criteria. I would recommend opening a Service Request and getting both local and remote array checked for any issues.
Thanks,
Raj
RobertDudley
2 Intern
•
448 Posts
1
March 16th, 2012 06:00
For SRDF/A the first rule is that the target array should be as fast or faster than the source array to destage the data coming over the link. For instance is you have a mirrored config on the source side and a raid-5 on the target, the target array is not as fast as the source.
Make sure the pipes are large enough to get the data over, you are not saturating the link and slowing down there.
There are drop codes that will tell you why the group dropped.
You should read this primus for very good information on setting up SRDF/A:
"What are the best practices for configuring SRDF/A?" emc142579
debmdig
27 Posts
0
March 26th, 2012 09:00
Well we finally identified the issue to be related to the B/W of the RDF link. Once incremented everything is working seamlessly !!
Thanks ..