This post is more than 5 years old
295 Posts
0
938
November 6th, 2012 13:00
2 x cx3-10c after recreate async mirror and RLPs, why when mirror is active host gets slow
steps done:
migrate source metalun to metalun wich has 3 components in 3 FC RG.
destroy and recreate mirror
re-create reserved lun pool in FC disks
and results seens to be the same.
the host accessing this meta is a vmware virtual machine
wich is in a hardware host conected to primary SAN in FC.
and the metalun is presented as a RDM disk.
does any one has idea where the bootleneck is, and why mirrorview/a when active slows donws the i/o and response of the host.
thank you
MC.
No Events found!
JonK1
2 Intern
•
247 Posts
0
November 7th, 2012 05:00
Hi Maynor,
MirrorView/A uses snapshots to make a golden copy of the data during synchronization. This causes the COFW (Copy On First Write) proces to start which generates a delay and traffic to your RLP.
If your RLP is undersized, this will limit performance of your complete mirror while it is synching. Also, regardless of IOps, the COFW will always introduce some extra latency so even in a perfectly sized environment you're bound to see a couple of extra milliseconds of latency.
AnkitMehta
1.4K Posts
0
November 6th, 2012 13:00
Could you please, rephrase the question?!
jelucho
295 Posts
0
November 7th, 2012 09:00
Thank you Jon
""""If your RLP is undersized, ."""
what does it means undersized,
in both sites i have available and enough fc RLP as litle metas of 30gigas each one, a half asigned to spB and a half to spA.
what can you suggest in order to complete the COFW step?
the impact i can see is in the VM that is using this source lun of mirror.
It is a mail server, and when a mirror starts to do a complete sync, all access to mail gets slows dramatically.
JonK1
2 Intern
•
247 Posts
0
November 7th, 2012 23:00
Hi Maynor,
Undersized not on capacity, but on performance. COFW generates a pretty heavy load to the RLP. Have a look over here for the performance calculations on COFW, on worst case three times as much as to the original LUNs.
Your best bet is using navisphere analyzer or such to monitor performance to your disks hosting the RLP. Try to see what load they are servicing. If they are overloaded (i.e. disks on 100% util), add more disks.