Random Write Performance with Write Back:
100% Random, 100% Write, 8K blocks, 8 DISK RAID 0 = 4850 IOPS
100% Random, 100% Write, 8K blocks, 16 DISK RAID 0 = 9779 IOPS
100% Random, 100% Write, 8K blocks, 32 DISK RAID 0 = 10400 IOPS
100% Random, 100% Write, 8K blocks, 16 DISK RAID 0 = 9779 IOPS
100% Random, 100% Write, 8K blocks, 32 DISK RAID 0 = 10400 IOPS
Performance with Write Through
100% Random, 100% Write, 8K blocks, 16 DISK RAID 0 = 7788 IOPS
100% Random, 100% Write, 8K blocks, 32 DISK RAID 0 = 13723 IOPS
100% Random, 100% Write, 8K blocks, 32 DISK RAID 0 = 13723 IOPS
1. In Active/Active mode cache locking will take place on writes when LD cache is set to WriteBack. This is the expected result since this is the price you pay when the objective is high availability.
2. The random write IO performance is greater with LD cache being set to Write-Through since when LD cache is disabled there is no cache locking taking place on writes between both controllers.
3. Why are the IOPS flattening out at 10K? At this point cache locking may have hit its max point (Controller to Controller communication latency on writes). The issue has been reported by other users and performance is being fine tuned by our development team (performance in general is always being fine tuned). The performance above is with in a respectable range.
4. What can you do to minimize cache locking when LD cache is set to Write-Back? It is recommend to leave cache mirroring enabled and simply enable LUN
Affinity. Configure the LDs in questions to be affinitive evenly across both controllers. This will minimize cache locking and also insure availability when LD cache is set to WriteBack.
Affinity. Configure the LDs in questions to be affinitive evenly across both controllers. This will minimize cache locking and also insure availability when LD cache is set to WriteBack.
The performance results should be much better with # 4 being implemented.