In my recent post about aggregate host I/O queue depth I shared both 100% SQL SELECT and 20% SQL UPDATE test results (SLOB) at varying LUN (ASM disk) counts. The LUNs mapped to XtremIO volumes but the assertions in that post were really applicable in most All-Flash Array situations.
I received quite a bit of email from readers about the granularity of session counts shown in the charts in that post. Overwhelmingly, folks asked to see more granular data. It so happens that the charts in that post were a mere snippet of the test suite results so I charted the full data set and am posting them here.
Test Description
The testing consisted of varying the number of ASM disks in a disk group from 1 to 16 host LUNs mapped to XtremIO volumes. SLOB was executed with varying numbers of zero-think time sessions from 1 to 250 sessions for the 20% UPDATE test and from 1 to 450 sessions for the 100% SELECT test. The SLOB scale was 1TB and I used SLOB Single-Schema Model. The array was a 4 X-Brick XtremIO array connected to a single 2s36c72t Xeon server running single-instance Oracle Database 12c and Linux 7. The array was attached via 6 runs of 8GFC Fibre Channel and multipathing was supplied by DM-MPIO. The default Oracle Database block size (8KB) was used.
Remember that the sessions are zero think-time in this testing, therefore, IOPS are a direct reflection of latency and in this case latency is majority attributed to host queueing as I explained in the prior post.
The prime message in this data is the Total IOPS values demonstrated at even low host LUN counts and, as such, it makes little sense to create complex ASM disk groups (consisting of large numbers of host LUNs mapped to All-Flash Array storage like XtremIO). Unless, that is, you manage one of the very few production databases that demands IOPS above 100,000. I know these databases exist, but there aren’t as many of them as some might think. High IOPS-capable platforms like XtremIO are generally used for consolidation.
If you click on the image you can get the full-size chart.
Enjoy!
Figure 1. 100% SQL SELECT.
Figure 2. 80% SQL SELECT with 20% SQL UPDATE.
Kevin Closson's Blog: Platforms, Databases and Storage 
Hi Kevin
Any chance you can post what the test environment consisted of (you know me, server spec, CPU Memory, HBA’s and what the XtremIO looked like, bricks, controllers, HBA’s etc).
G
Look at it now.
thanks thanks.
G
Kevin
Unless, that is, you manage one of the very few production databases that demands IOPS above 100,000. I know these databases exist, but there aren’t as many of them as some might think. ==> With 64-bit Oracle & the ability to create SGAs well over 2GB, we just don’t see DBs generating anywhere near 100,000 PIOs any longer. The “typical” heavy hitting DB (I see) generates around peak 25,000 PIOs, db file sequential read requests.
nosebleed IOPS are the result of consolidation. Agreed.