I'd like to have your point of view or experience regarding write cache activation (or not) in a SSD context.
In our case : 2 SC8000 wtth 3 tiers (SSD SLC - SAS 15K - SAS 7K)
In a recommended profile, the Storage Center documentation advises to disable write cache, argumenting that write IOs will occur on SSD and latency on SSD is comparable to NVRAM latency.
Ok... so we made a simple test : 1 Windows 2008 R2 server with 2 LUNs in recommended profile.
We simply copy/paste a big file (8Go) from the first LUN to the second LUN (the second is write cache disabled).
We notice that the copy operation is just 30% to 40% longer than with cache enable....
So what ?
We tried with another server (Windows 2003) --> same thing.
We tried with other NTFS cluster block size --> same thing.
We tried to modify HBA Queue depth --> same thing...
So, for the moment, I don't disable write cache, even for SSD LUN...
Yes, these are physical boxes with FC. And no Anti-virus software...
In fact, I've noticed this problem on a production server hosting a big SQLServer database (2To). We have restored this database and we was suprised by the low write rates (4Go/Min) where we used to be at 6Go/min.... when I've enabled the write cache.. oh surprise... the write rates was ok...
I've also made some test with VMware ESXi Host, some VMs clone operation, and, with VMware, all is normal... (better without write cache)...
So this issue is "windows dependent"... but where is the tips ?
I am assuming these are physical boxes - there are some interesting things about the Windows i/O system that can cause wierd issues. In general the SSD should write as fast or faster without the write cache turned on. It will also reduce the latency (which can be big with certain applications).
You could try something with a Linux server I guess - or get Condusiv's Velocity demo and see if that makes a difference. I would also check for virus scanners and other things that can drag down I/O. I sometimes recommend people make a RAM disk on the Windows server in question and see if performance increases between the RAM disk and disk. If not there is generally something effecting the whole I/O system.
The IOmeter not being slow could mean you have all sorts of trapped potential in those servers :)
Go into the Windows Device manager and check the properties of each of the LUNs. Make sure you check the advanced settings in particular to see if you are caching all your writes through the OS.
Also - I would probably pin the MPIO setting to a single port for this type of test. That way you can make it easier to see if there is a FC related issue. Put each lun on a different port.
HMA59
24 Posts
4884
0
Posted April 2nd, 2014 08:00
Yes, these are physical boxes with FC. And no Anti-virus software...
In fact, I've noticed this problem on a production server hosting a big SQLServer database (2To). We have restored this database and we was suprised by the low write rates (4Go/Min) where we used to be at 6Go/min.... when I've enabled the write cache.. oh surprise... the write rates was ok...
I've also made some test with VMware ESXi Host, some VMs clone operation, and, with VMware, all is normal... (better without write cache)...
So this issue is "windows dependent"... but where is the tips ?