Volume or Qtree snapmirror?
I started with volume and had similar problems with big delays. As I remember, the destination was doing constantly a "deswizzling". Our lokal support (not netapp) told me to migrate to qtrees about this deswizzling but this did not help.
Occassionally there is some noticable activity on the destination and the source node after a transfer, but it should cause the delays you are experiencing. Deswizzling is normal on destination volumes.
deswizzling should only be an issue if your accessing data on the destination volume, and seeing as you switched to qtree snapmirror and noticed no change, this might not be the problem.
What is the snapmirror schedule?
I did not use sync because I expected slow performance of NFS because the write will be accked after writing the blocks to both netapps. so I started with one minute:-) but had increased that quickly to 5 and the 15 minutes. now i use hourly scheduled snapmirror to better be able to find the reason of the problem.
Hourly seems reasonable.
Synch or Async?
asynch. is anybody using synch snapmirroring?
I've used it. Typically, if you're considering using a really small window, (say snap every five minutes or everyone one minute) then I'd recommend changing to sync if the filers are directly connected. Not applicable in every case, but certainly an option.
Are the disks identical at both ends? What type and quantity of disks?
both files are identical and purchsed at the same time on beginning of 2006. 14 300GB FCAL disks, DP, one spare
Excellent!
I don't know them, any link?
http://www.netapp.com/library/tr/3446.pdf
What sort of cpu utilization are you seeing on the source and destination?
I don't know what is normal. I see loads from 20 to 70 % on both filers. that is another problem for me. because ontap is constantly doing some maintenance on the filesystem (which souns good) I don't see what the real load is.
Unless it's constantly pegged at 100%, you're usually ok. Granted, we haven't dived into a statit session, but nothing sounds out of the ordinary.
My suggestion at this point would be to double check the links between the two filers to make sure you aren't dealing with a speed/duplex mismatch or other issue. (Run netdiag -v).
Otherwise, you've probably encountered a bug. (Doing a quick now search for snapmirror bugs is illuminating. There are a fair number of #2 slowness bugs related to snapmirror) I suggest upgrading to 7.0.5 on both the source and destination.
Regards, Max
I have a maildir setup with slightly more files than yours and about 100GB more data. I'm Volume snapmirroring over 100Mbps ethernet, and It takes ~10-15 Minutes to mirror the deltas, which are about 6-8 GB. I'm running
That sounds to me as you have a moderate snapmirror schedule. If you have 7 GB deltas for about 250 GB I assume that you are doing the snapmirror only every some hours??? or you have very busy users:-)
I am (was) so naive to expect that I could be able to let the second filer follow the first with one or two minutes delay. It should not be a great problem to transfer the writes to the second filer and doing the same operations there on the fly. but now I think, that netapp ist doing snapshots for snapmirror and then calculates the changes and then transfers them to the destination. this is a lot of work to do for the small poor filer and it will not scale well with much small files. But perhaps I completly misunderstand the whole process.
7.0.5. If memory serves me correctly, I upgraded because I saw some ugly Snapmirror bugs associated with 7.0.4 as a preventive measure.
That gives me some hope about the future when we upgrade to 7.0.5.
Otherwise snapmirror works at the block level for transfers, file sizes shouldn't matter.
I don't think, that the transfer is the problem. It looks like some overhead in the filesystem for me.
Thanks for all responses yet. Everybody on the list I wish a fine 2007, thomas