SnapManager for Exchange is Slow

[CHARLES_PEARSON]

We're running SnapManager for Exchange on Exchange 2010. If I want to browse and delete backups, the interface is slow...and I mean SSLLLOOOOWWW. I'll click to expand one of the data stores to view it's list of backups, and this expansion operation alone will take a good 4-5 minutes. Once the backups are finally displayed, I'll right click and delete one, then this operation as well will take a good 4-5 minutes. I'm in the process of cleaning up a bunch of old, abandoned snapshots, and it is taking me forever.

Is this just the way it is, or is it possible that something just isn't set up right in our environment? I'm curious what other people's experiences have been.

[MURRAYCH1]

Is your back end C-mode or 7-mode?

We have the same issue.  It started for us when we moved to a C-mode setup, and the explanation I was given by NetApp support was that SnapDrive is hella slow interfacing with C-mode (I cannot remember the specific reason why).  I was told "it would be addressed eventually".

[CHARLES_PEARSON]

Yeah, we just went to C-mode a couple months ago. That must be the issue then. I guess I have noticed since the migration that creating new LUNs through SnapDrive is also slower than a three-legged tortoise.

[oweinmann]

Hi,

has this problem ever been resolved? We see the same issues since we moved to CDOT. Currently we are running CDOT 8.3RC1, Exchange 2010 SP3 RU3, SnapDrive 7.1, SME 7.1, HostUtils 7.0, DataOntap DSM 4.1

[AndyD]

The issue is in the iimplementation of the TCP stack within FreeBSD on Data ONTAP.  It affects the response time of ZAPI calls (such as from SnapDrive), due to the way that FreeBSD inserts wait packets into a TCP request.

There is currently a workaround available for these, so I suggest contacting NetApp Support for assistance in applying this.  The workaround entails modifying one of the running parameters within ONATP, so it should be done in conjuction with a NetApp engineer.

When creating the case(s), please ensure you open the case as a SnapDrive/SnapManager case so it is routed to the group with the right experience for dealing with this issue.

[BCBrad]

We are running into the same issue, with the current revisions of SnapDrive (7.1.2 on Windows, 5.3 for Linux) and SnapManager for SQL (7.2) and Exchange (7.1.1). This is against cDOT 8.3P1. We see the same issue whether using HTTP or HTTPS transport protocol (AFAIK, RPC auth is not supported with cDOT). The KB article linked below seems to describe the issue, though it suggests the issue was only present in 8.2.2P2 and earlier. I'll try testing this tomorrow and report back. We went from 1 minute cloning operations on 7-mode, to 20-30 minutes to do the same in cDOT...unbearable.

https://kb.netapp.com/support/index?page=content&id=2021472

[ONDREJ_STAVINOHA]

BCBrad,

did you manage to do some testing where improvements could be observed? We seem to be hitting similar issue with SMSQL 7.2 and cDOT 8.3.1 P1