SLOW Cifs performance after snapmirror break and subsequent resync

[DinoBob]

We have been seeing an issue which is affecting our systems only when we break our snapmirrors for DR purposes and then fail back afterward. After the DR operation concludes and we are resynced to our original relationship, CIFS performance is much slower. We particularly see this when accessing Office files. We suspected this for a while and confirmed it by creating a "clean" test volume, then running the very same data analysis job against the test volume and an existing production volume. The test volume was just as fast as we expected. The production volume was about 6x slower to run the job. We can definitely track the beginning of the issue to the failover/failback. Does anyone have any ideas? FAS2552, OnTap 9.5.

[GidonMarcus]

Hi

to answer directly your concern - the only operation i'm aware of to run after snapmirror break is a deswizzling scan, and it can be quite impacting if the deswizzling could have not run after each snapmirror https://kb.netapp.com/app/answers/answer_view/a_id/1003882

having said that - this to actually impact just day to day office access sound maybe a bit odd. i can give some idea's to try and follow:

are the two systems the same spec? have the same network design?

what level of object do you see the latency in ? (Volume/Lif usually shows client related latency - aggregate is usually down to the local system)

are the client have the same connectivity ? (WAN connection with latency can be very impacting for day to day use like office files)

Are the clients negotiating the same protocols? (SMB version and kerberos vs NTLM - lack of SPN can cause issues.)

i think that after isolating common causes. the right thing to have is a few wireshark samples from each scenario

Gidi