Romex Software Forum

Request for comments / advice:
For hardware, I have two 2 TB SSHDs in a RAID 0 (Stripe) array. I'm using 128K stripe size. The drive is GPT, and is my primary disk. It's formatted as NTFS with a 16K cluster size. (Since HDDs are fast at sequential access, this will keep more of the data sequential at the cost of disk space. The SSHDs I'm using are Seagate: ST2000DX001s. They have 8 GB of SSD cache in each of them, but they don't seem that much faster than standard 7200 RPM HDDs for any of the benchmarks I've run...)

The SSD I'm using for L2 is the Samsung 840 EVO 250 GB. I have IRST turned on (64 GB of SSD) in maximized mode for accelerated writes (PrimoCache does not currently support accelerating writes with SSD storage, only RAM. I have a feature request here: viewtopic.php?f=35&t=2714 ).

I have Primo Cache configured with a single cache job for the entire drive which contains two partitions: MSR/Recovery - 300 MB, and C:\ - 3.63 TB.

The single cache job uses 4096 MB of OS Managed Memory (MM). And uses the MAX of an L2 storage partition on the same SSD drive as IRST (152 GB in size).

The block size I'm using is 32KB (I chose this as a trade-off, since the overhead of 16 KB is ~2 GB, and 32 KB is only ~1 GB).

The Cache Strategy I'm using is Read-data & Write-data, with Deferred Write set to 60 seconds. The machine is plugged into a UPS (a "dumb", low-end UPS, that does not shutdown the machine during a power-outage, but will at least keep it running for a little bit during power flickers, etc.).

Is this the optimal PrimoCache configuration for this setup? -- Is it better if the block size matches the NTFS cluster size (i.e. 16 KB in my situation, 4 KB in most others), or is it better if the block size matches the RAID stripe size (128 KB in my situation). Is it better to have two cache jobs, one for reading, and one for writing (potentially with different block sizes)? What do you think?

I plan do to a lot of heavy disk work on this box (Databases and multiple virtual machines at once to simulate small server farms, etc.), it has 32 GB of ram, but the VMs and such are going to be eating a lot of that (right now I'm giving over 5 GB total to PrimoCache, though I would prefer to keep it closer to 4 GB... but this is an acceptable trade-off -- would moving it down to 16 KB, and upping it to 6 GB be worth it? will it be a lot faster, or only a little faster, or will I even notice it at all?).

My OS is Windows 8.1 (64-bit). I plan to use MS SQL Server, HyperV, and VirtualBox (among others).

(Not sure if it makes a difference, but if the trial goes well, I plan on purchasing the Business License for this PC, since I use it for work.)

1. No need to cache MSR/Recovery partition.
2. In current version 1.0.1, it is better to make block size equal to cluster size (16KB), however you may also use 64KB block size to reduce overhead.
3. Please note that Defer-write may cause data loss in cases of power failure and system crash/hang. It still have potential risks even you have a UPS because of system crash/hang. So keep attention to your important data if you want to use the defer-write feature.

For databases, it may help to place the indexes on the fastest drive (SSD) if you can store them separately. I would also suggest monitoring process memory usage (using Process Explorer or Process Hacker) to determine maximum RAM usage for your system. Subtract this from your 32GB, subtract another couple of GB to give a safety margin and that should give you the amount you can allocate to PrimoCache L1 without hampering application performance.

I suspect that your setup may have too many levels of caching (Windows file cache -> Primo L1 -> Primo L2/IRST -> SSHD cache -> SSHD drive) and would suggest you consider skipping Primo L2/IRST and using your SSD for speed critical data (system files/registry hives, database indexes, scratchpad files, etc) instead. However this would mean a system rebuild (SSD as C: containing Windows + programs, SSHD RAID as D: containing data) to get system files onto SSD.

If you are going to use deferred write, I'd suggest sticking with the 10-second default. Extending this seems to provide very little extra performance (though your mileage may vary...) while increasing the risk of data loss - which as Support has noted can occur with a crash or hang.