Unsolved
This post is more than 5 years old
14 Posts
0
3259
SRDFA write-pending limit reached
Hello,
We received a message...RDFA_SESS_DROP_WPL_ENBL...documentation states that this
"SRDF/A Session dropped, write pending limit reached. Host throttling enabled Error"
Does this mean that the network link between the R1 and R2 frames has slowed down for some reason, or network link dropped, although the client states there were now network issues, or the R2 frame slowed down and could not keep up?
SYMEVENT did find this..
Sat Jan 18 03:20:58 2014 RE-9G Symm RDF (02) Error 0x004a
SRDF/A Session dropped, write pending limit reached.Host throttling disabled
The odd part is the director RE-9G is offline and is not used we are using H directors which symevent has not identifed any of those showing with any issue.
Quincy561
1.3K Posts
1
January 22nd, 2014 07:00
Another possibility is that the host workload increased.
ACPRATICO1
14 Posts
0
January 22nd, 2014 07:00
That is a possibility, but knowing that the R1 devices during heavy processing/IO we have not reached this limit during those times, or when the client makes several changes to the data on the R1 side that this does not happen. When this was received there was not much processing going on at the time the write-pending limit was reached. It was not identified until several hours later that one of the RDF GROUP links was suspended.
Fenglin1
2.1K Posts
0
January 22nd, 2014 17:00
Have you seen the WP track going down after the director is back online and link recovered? You'd better to switch the SRDF to adaptive copy mode which will move slot faster. See the KB for the steps: https://support.emc.com/kb/9619
Rasmmacias
108 Posts
0
January 23rd, 2014 02:00
Verify that the number of invalid tracks is below 30,000
IMPORTANT
It could be a dangerous situation if SRDF/A mode is activated with a large number of invalid tracks. It is a best practice to switch into SRDF/A mode once the total amount of invalid tracks has fallen below 30,000. Activating SRDF/A with a large number of invalid tracks owed to the R2 side could overload the DA, flood the RDF link, and flood the R1 cache. All of these scenarios could cause the SRDF/A session to drop again. At a minimum, it will have a negative effect on cycle time and could cause other active SRDF/A sessions in the Symmetrix array to experience elongated cycle times.
Before switching into SRDF/A mode, you should remain in adaptive copy disk mode until the invalid track count falls below 30,000, or one cycle set of data. This way you greatly minimize your risk of flooding the cache or your link.
Using the example shown below, enter the symrdf query command for your device group to determine the invalid track count.
symrdf -g pocsun100data query -i 5
Device Group (DG) Name : pocsun100data
DG's Type : RDF1
DG's Symmetrix ID : 000187461502
Source (R1) View Target (R2) View MODES
-------------------------------- ------------------ ----- -----------
ST LI ST
Standard A N A
Logical T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF Pair
Device Dev E Tracks Tracks S Dev E Tracks Tracks MDA STATE
-------------------------------- -- ------------------- ---- -----------
DEV001 00E1 RW 0 25891 RW 00E1 WD 0 0 C.D SyncInProg
DEV002 00E2 RW 0 0 RW 00E2 WD 0 0 C.D Synchronized
DEV003 00E3 RW 0 0 RW 00E3 WD 0 0 C.D Synchronized
DEV004 00E4 RW 0 0 RW 00E4 WD 0 0 C.D Synchronized
Total -------- -------- -------- --------
Track(s) 0 25891 0 0
MB(s) 0.0 809.1 0.0 0.0
Legend for MODES:
M(ode of Operation): A = Async, S = Sync, E = Semi-sync, C = Adaptive Copy
D(omino) : X = Enabled, . = Disabled
A(daptive Copy) : D = Disk Mode, W = WP Mode, . = ACp off
The R2 invalid track columns in this example show that the amount of invalid tracks has fallen below 30,000. Device group pocsun100data has 25,891 invalid tracks. This means that it takes just one SRDF/A cycle switch to make the RDF pairs consistent for both device groups