I don't see a limit on the vm side. on my tests (Using FIO), I got 450K iops @8k random read from a single VM/single blade. From the disk side, thin vv passed through as physical RDM disk using ESX 5.5 u2
In order to drive the IO up, I used 8 jobs/files. numjobs (threads)=16, IOdepth = 4, so this is 512 reader threads on 8 files. Latency also in the 0.7 range
do a sanity check on the SQLIO parameters, it could be you are undriving the tool, and it may seem as a limit, but it's not. Increase files/thread/QueueDepth until you get good IOPS at a reasonable latency.
When using a SINGLE file, you will hit a wall. Also if you use small files, your results will be skewed upward, because you are getting 100% cache hit on your reads. in my case I had to bump the file size up, to 128GB for a total test spread of 1TB. (my cache is 32GB per node, 128GB Tot) so I look for a <10% cache to data ratio to be sure I am hitting the disks most of the time. check statcmp during your sqlio run to verify your iops are not just comming from cache.
|