The only indication that the 1GB RAID cache with the battery pack was installed (other than a speed increase in writes) was the RAID controller message displayed on the server's console during power on. I seem to recall that a message was initially displayed after installing the 1GB RAID cache with the battery pack indicated that the battery pack was not fully charged and RAID performance would not optimal at that time.

As far as partition alignment issues are concerned, I have no idea if that's a possibility. However, the datastore creation and VM creation/installation was performed via the VI Client.

I have just discovered that HP ship all their disks with the onboard DISK write cache switched off (I am guessing that this is just in case you are using zero Mb controller with no battery backed cache and maybe you do not run a server with a UPS either); I guess I must have missed the great big NEON sign that said - "for customer safety we have ensured that your write performance will be abysmal - just in case you are silly enough to run without safety nets").

I have not been able to go back to check that switching the ondisk caching back on helps (4am site visit tomorrow am will give us the results - argh). I hope the above diatribe and debrief helps anyone else.

Of course - I am wondering if people are running their server with decent levels of battery backed cache, but that may still have the default ondisk cache off - I guess they might never realise that the ondisk cache is OFF and could be enjoying even better performance - what a waster that would be.

Makes you wonder why anyone works in IT - when the default settings make an expensive SAS raid controller running mirrored disks slower than a very slow thing indeed.

I will report back late late tomorrow or perhaps even Tuesday when my brain returns from its hiding place. Any feedback welcomed.

Due to the cache issue, the scan effect dragged down the entire
server performance. Disk queues could be as high as 40-50 for tens of
minutes at a time.

The XMON background scanning can be turned off (in fact some
recommend that it is turned off, despite it being on by default); We
have resolved the overall issue by adding 512Mb battery backed cache to
the controller and performance is much much much better and I believe
that if we had started with the cache, we would never have noticed any
issues at all.

Please note that the ESET NOD32 XMON issue is not at fault - it simply highlighted the disk performance issue.

My main gripe is that for some reason HP sell the current range of ML330 G6 generation of servers with NO=Zero cache memory as standard on the P410 controller! Silly me thought that they would not possibly sell something so handicapped.Not only that, when you decide to upgrade you can either purchase a 256Mb module or 512Mb with battery. Why not 256Mb with battery?

FYI we now get disk queues of <2 most of the time and occasional blips of higher queue levels - but it is like comparing the norfolk broads with Wales! IOMeter tests show throughputs of 160MBs reads and 230MBs writes (not bad for 7200rpm mirrored pair) - which compares to early non-bbwc results of approx 66MBps read and 52MBps writes. These non-bbwc results are worse than the headline values indicate due to the type of iometer test and also the fact that the disk queue length was so high too during the test.

Still a learning exercise for me - (1) ESXi NEEDS a properly cached controller for decent write performance - more so that running a physcial box it would seem and (2) not to take HP specs at face value.

I would love to get some feedback from HP on this matter as I was intending to standardise on their kit as we seek to use ESXi for all our clients i.e. why sell a raid controller with zero cache memory and not insist on cache upgrade or at least make it very clear tha you are buying something which for many purposes will be too slow? I sign off somewhat bemused.