RAID CONTROLLER RAM 2GB?

What RAID level do you intend to use?

The advantage of having cache RAM on a disk controller depends on how repetitive the accesses are.  If there is lots of disk traffic and you are hitting the same blocks in the same databases over and over again the gain will be excellent.  If there is lots of disk traffic but the accesses are distributed across many files and randomly within those files the gain will be small.  If there is little disk traffic there won't be any perceptible gain.

You stated:

Nothing is tremendously I/O intensive.

Since memory is cheap you might as well hang it on the disk controller, but in this environment don't expect to see much of an improvement.  Controller cache's big gain is in I/O intensive applications such as databases.

Don't forget that the host operating system uses unused memory for disk cache.  In a 32 GB system that is not busy 24 GB of that might be used for disk cache.  At some point it makes no sense to have three levels of big disk cache - one on the controller, one in the host operating system and one in the VM.  The same sector might be cached three times, which is just a waste of memory.

Note that if the controller uses memory for write cache, a larger write cache means more lost data on a crash unless (a) the controller has battery backup or (b) the flush interval is set low ... which defeats the purpose of write caching.

As Dr. Klahn mentioned, the value of larger cache memory is highly dependent on your I/O access pattern.

For highly random, non intensive I/O lower memory is sufficient.

For applications reading massive amounts of contiguous (sequential) data, cache memory may help.

12GB/S 2GB Cache yes, of course, this will increase the i/o performance up to 12GB/per second, but along with the compatible hardware required to get the maximum i/o output .. like 12GBps performance SAS/SSD HDDS .. as well

all the best

"Would there be a substantial difference if I could update it to 4GB?"

Since it is not available with 4GB that question is meaningless. The memory is soldered on board, under the cache battery IIRC.

One additional point to consider is that if you are using VMs, most writes will tend to require a sync response to be returned (depending on the hypervisor and the configuration). This confirms that the data has been reliably written to persistent storage. If you have a controller with battery backed RAM (the spec for the one you mention states that it does), and your use-case supports it, having sync writes return almost immediately once the data is committed to the controller's RAM will be significantly more performant than waiting for disk writes to complete. Naturally, if the controller's RAM fills, then sync write performance will drop to what is supported by the underlying disks. You are potentially creating a single point of failure working this way, but for some set-ups, it may be considered acceptable.

As some other experts have said above, VMs, hypervisors and storage systems themselves have caches that are used to help speed up IO. There is a case for suggesting that bringing cacheing closer to where it is actually being used (so using RAM for database buffers, for example) is often better because the service or application itself knows more about usage patterns and likely access more than a controller could ever predict. Disk controller RAM is probably quite expensive GB for GB when compared to standard server ECC RAM, so consider this too. Your money may be better spent on other system components.

Finally, it's worth noting that software RAID may be preferred over hardware RAID. Often, hardware raid is proprietary and if the controller fails, finding a replacement that can read the data may be problematic. Not all RAID controllers handle all of the parity calculations for RAID (where required) and offload it to the CPU so do check the specs of what you plan on using.

Testing any set-up and tuning is likely to be very important in anything more than a simple set-up.

Hi Dr. Klahn

Thanks for response

The machine is going to have quite a bit of free RAM.  It is a single host running esxi, Essentials actually.  easily 50-60% of RAM free for growth.
So that being said it sounds like we are good.
Thanks for the feedback!

Thanks everyone!

Unless a lot has changed in the last 5-7 years I would not use software RAID.

Thanks!!

WRT software RAID, a lot has changed with CPUs, controllers, and file systems. It also depends on the hypervisor you choose. It's definitely worth reading more about before making a final decision.

All the best.

Software RAID is expensive under ESXi since you need a vSAN, although StarWind vSAN is free.

Guys - awesome info - thanks for confirming things for me!

As Martyn implied, if high performance I/O is required, best to stick with a non VM partitioning mechanism like LXD, where I/O runs at hardware speed, rather than going through a very slow, VM layer.