2012-01-19 03:35 AM
We have a speed issue with our new Netapp unit.
We have the following setup: -
1. VMWare VM with RDM Luns attached to paravirtualised SCSI
2. SQL Server 2008 R2
3. FC Connectivity
4. 2240 on ontap 8.1
3. Filer 1 contains DATA and LOG LUNS on its aggregate containing 2 x RAID DP 11 x 600GB SAS Drives
4. Filer 2 contains BACKUP LUN on its aggregate containing 2 x RAID DP 11 x 600GB SAS Drives
5. FC connectivity zoned to one server for error testing.
1. Create new BACKUP LUN on filer 2 map and
2. Run native sql backup to this LUN
Returns 150MBps reads and writes
1. Then delete .bak file from backup Lun
2. Run native sql backup to this backup Lun
Returns 80MBps reads and writes
Windows file copies seem to run fine from DATA and LOG Luns to the Backup Lun regardless.
Have some perfstats but not sure what to look at. Any ideas to why this happens? Identical VM on same VMWare host but using an EMC CX4 no issues with the above.
2012-01-20 02:53 AM
Are there any snapshots present? Did you look at CPU utilisation? Can you post some perfstat (or sysstat) results?
2012-01-20 03:47 AM
Do I understand correct that you backup twice to the same LUN but the performance is worse after deleting the first backup?
How much data do you have in the Backupdump? Do you use compression (the SQL Server Feature) for the backups? Are the LUNs preallocated or thin?
2012-01-20 06:22 AM
Thanks for posting. I forgot to add this is on a Windows 2008 server (but you probably guessed this due to the SQL version!).
Yes we backup twice to the same Lun but the performnace is worse after deleting the first backup. Not using SQL compression, File size on complete backup for this SQL Server is 250GB. Tried both preallocated and thin.
Radek can you PM me your direct contact details and I will send some before and after perfstats? I have had Netapp look at these and he is saying there looks to be no bottlenecks with the filers however second pass their are more reads than first pass occuring on the backup Lun. He mentioned Netapp's aren't great at single threaded writes. Is a SQL backup a single threaded write?
Also I forgot to add Windows copies do only run at 80MBps also.
2012-01-20 08:24 AM
I'd rather say NetApp ain't great with large sequential reads. Some improvements have been made over the years (e.g. read-ahead caching algorithm), but it still isn't their strongest feature.
It's a long shot, bit *if* there are any snapshots, the volume in question may get more fragmented after a large file is deleted - and this may lead to worse performance (potentially).
2012-08-01 04:01 AM
we have a customer currently facing similar issue, with almost similar config (FAS2220 instead of 2240)
Did you managed to fix your issue ? If so, how did you fixed it ?
2012-08-02 08:11 AM
Do a reallocate measure -o on the volume and see if you have issues with fragmentation.
Did you add any disks to the aggr this volume is on after the aggr was created?
Is the NVRAM doing back to back checkpoints because it's full?