SLOB using Violin 6616 on Fujitsu Servers

I’ve been too busy to blog recently, which is frustrating because I want to talk more about subjects that are important to me such as Database Virtualization and the great hype around In Memory Databases. However, in the meantime I’d like to share some results from running SLOB (the Silly Little Oracle Benchmark) on Violin Memory flash memory arrays.

I’ve posted some SLOB results in the past, such as these. However, at the time I only had some Nehalem generation CPUs in my lab servers, so I was struggling to generate anything like the level of load that a Violin flash memory array can create.

Now I have some power :-). Thanks to my good friends at Fujitsu I have some powerful servers including an RX300 on which to run some SLOB testing. This is a two-socket machine containing two quad-core Intel Xeon E5-2643 Sandy Bridge processors. Let’s see what it can do.

First let’s run a physical IO test using a Violin Memory 6616 array connected by 8GFC:

Load Profile              Per Second    Per Transaction
~~~~~~~~~~~~         ---------------    ---------------
      DB Time(s):               95.9            5,511.9
       DB CPU(s):                7.1              406.0
       Redo size:            2,729.7          156,939.6
   Logical reads:          192,361.2       11,059,614.8
   Block changes:                6.0              347.5
  Physical reads:          189,430.7       10,891,128.1
 Physical writes:                1.9              110.6

Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                           Avg
                                                          wait   % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
db file sequential read         119,835,425      50,938      0   84.0 User I/O
latch: cache buffers lru chain   20,051,266       6,221      0   10.3 Other
DB CPU                                            4,466           7.4
wait list latch free                567,154         572      1     .9 Other
latch: cache buffers chains           1,653           1      0     .0 Concurrenc

The database block size is 8k so that’s 189k random read 8k IOPS. However, as you can see the Oracle AWR report does not calculate the average wait time with enough accuracy for testing flash – the average wait of my random I/O is showing as zero milliseconds. However it’s very simple to recalculate this in microseconds since we just need to take the total time (50,938 seconds) and divide by the total number of waits (119,835,425) then multiply by one million to get the answer: 425 microseconds average latency.

Now let’s run a redo generation test. This time I’m on a Fujitsu PRIMEQUEST 8-socket E7-8830 (Westmere-EX) NUMA box, again connected via 8GFC to the Violin Memory 6616 array. Remember, this test is the one where you create a large enough SGA and buffer cache that the Database Writer does not get posted to flush dirty blocks to disk. As a result, the Log Writer is the only process performing physical I/O. This is a similar workload to that produced during OLTP benchmarks such as TPC-C – a benchmark for which Oracle, Cisco, HP and Fujitsu have all recently used Violin Memory arrays to set records. Here’s the output from my redo SLOB test:

Load Profile              Per Second    Per Transaction
~~~~~~~~~~~~         ---------------    ---------------
      DB Time(s):              197.6                2.8
       DB CPU(s):               18.8                0.3
       Redo size:    1,477,126,876.3       20,568,059.6
   Logical reads:          896,951.0           12,489.5
   Block changes:          672,039.3            9,357.7
  Physical reads:           15,529.0              216.2
 Physical writes:          166,099.8            2,312.8

Over 1.4GB/second of sustained redo generation (the snapshot was for a five minute period). That’s an impressive result. Unfortunately I’ve had to sit on it for a month now whilst the details of the Violin and Fujitsu agreement were worked out… but now I am able to share it, I am looking forward to setting some new records using Violin Memory storage and Fujitsu servers. Stay tuned…!

[Update: I confess that in the month or so since I ran these tests I’d forgotten that I didn’t use SLOB to produce the results of the redo test, although it has a perfectly capable redo generation ability… the redo test output above is actually from a TPC-C-like workload generator. The physical read tests are from SLOB though – and it still remains my favourite benchmarking tool!]