time dd if=/dev/zero of=/tmp/test.txt bs=1k count=1000000
1000000+0 records in
1000000+0 records out

real 1m1.819s
user 0m0.300s
sys 0m2.380s

the I/O is less to 20MB/s... You can try the same test and past here the output?

Thanks in advance!

As a point of interested, I performed a clean shut-down on my test ESXi box (which has 512MB BBWC on a Dell Perc 5i), turned it off and disconnected the battery for a few moments. The result was that the volume was corrupted and I had to restore all my VMs from a backup - I would conclude that enabling write-caching anywhere without battery backup is pretty brave.

Tonight I have been over to the client out of hours and run a few tests. Running IOMeter with 2 workers with 2 access specifications 32kblocks with 100%read and 0%random and the 2nd with 32k blocks with 100%write and 0%random for 1 minute for each of the access specifications (2 minute total run); (In simple terms a seq read test and then a seq write test); I then proceeded to delberately switch OFF the ondisk caching (which I had in fact switched on during initial build - just thought I had not) ran the tests and then reran the tests with ondisk caching switched back on. FULL physical server and virtual server power down and restart for completeness before each test.

Summary Results:

OnDisk caching OFF: avg 47MBps read and avg 5.6MBps writes

OnDisk caching ON: avg 66MBps read and avg 52MBps writes

So that is looking quite good; unfortunately I do not have exactly the same results for comparison from the previous 24 hours of poor performance; although the closest comparison would seem to be:

Bad/Weird State with partial caching?: avg 37MBps read and avg 29MBps writes

Interim conclusion: I suspect that perhaps the disk/array problem after the server physical move may have left the ondisk caching in an odd state?

What I would say is that although things seem to be better - at times the server avg disk queue length is still higher than I would normally be happy with - I suspect that we may need to invest in some BBWC kit.

Just for completeness: the disks used in this server are 3x 250Gb "Midline" disks pn: 458926-B21

If anyone has the same setup but with 256 or 512Mb cache with or without battery backup - I would be very interested to see your results; I can send the iometer settings file across if desired.

My own virtualised server running running in a similar fashion using an LSI Megaraid SATA 300-8XLP SATA II raid adapter with 128Mb embedded cache and 2x1.5TB pn: WD15EADS mirrored disks gets figures of 92Mbps read and 110Mbps write! seems odd, but overall appears nippy enough in practice and no long disk queue during any of the normal usage or iometer workloads tested so far (obviously not trying hard enough).

We recently added the BBWC to a DL360 Gen 5 that was performing slowly in our data centre. I took the server down to physically install the battery. Then booted the server with Smart Start to ensure that the cache ratios were setup to the defaults (75% write and 25% read). They were there automatically. I then booted the server back up into VMWare ESXi 3.5.

Approx 24 hours later, i confirmed that speeds were approx 60-70MB/s...which was a huge improvement over previous speeds of 2-4MB/s.

Thus, I did nothing else other than shut down, plug in battery and turn back on. It's worth noting too that I had a P400i with 256MB of cache and I left the 256MB of cache, just added the BBWC and our problems are resolved.