New toys are always fun! When Oracle announced their “Small” ODA’s in the X6-2 generation, we were excited to test them. We were not the only ones, so it took a while before getting one, but the first week of january, it was playtime. An ODA X6-2M was delivered to our demoroom and testing could begin.
Normally I would start a blog post by “how to install” it. Actually this is very simple and very well documented. If you want me to blog about it as well, just let me know.
The nice thing about the database appliance is, that in the X6-2 generation, it is now possible to have single instances which can host standard edition. This is a good thing. One of the reasons you want to consider this, is that step-in costs can be reduced. For smaller companies, you get a database in a box which is just working. Nice, isn’t it?
So how does it perform?
Well … first things first! Slob. The wonderfull tool of Kevin Closson (you can find him here http://kevinclosson.net ). Slob helps stressing the storage so that you can find out how your system is behaving. It always one of the first things I run on a new system.
Marco Mischke (@dbamarco) was also playing with the X6 and he discovered an important performance difference between running your database on ASM and ACFS. It has been classified as a bug and “fixed” in the latest ODA image. Guess which version I installed on the ODA? Right, the latest one. So we got in touch and the first slob test was good. It reached far higher, so the problem looked to be fixed.
But looking a bit further, I wanted to test on ASM as well.
You know? I will provide the results you’re looking for by now 🙂
Ok First: ACFS, here we go.
So with a limited set of workers we reach up to about 325000 iops. Given that the system has 20 cores available, this results into 16250iops per core.
If we translate that in MB/s we get this:
I left out the latencies here to make it a bit more clear but it peaks to 2,5GB/s at it’s most. So here are the latencies over the tests:
I put it into excel as well:
max read latency 2587.22 us 2.58722 ms max write latency 2094.74 us 2.09474 ms
These are the maximum latencies during the test, so merely at the end. In my opinion, this is good.
If more details are needed, drop me a message and I will provide more information.
Let’s move on to ASM, exactly the same database, parameters, etc,… I love 12c! you can move the datafiles online, so that’s how it has been done.
ASM, your results please.
Oops, what’s that? 800.000 iops in read! And the write ones are only slightly better.
Then we go to the throughput:
So asm is faster than ACFS. I was expecting it to be a bit faster, but not this.
For completeness the latencies:
And then the figures:
max read latency 2508.65 us 2.50865 ms max write latency 2893.87 us 2.89387 ms
This look likes expected. Good.
I talked to my team-lead and performance tuning expert, Geert De Paep about this behaviour. You could see the lights in his eyes, he wants to test it as well. So I’m looking forward to his blogpost as well. I can tell you already, by doing the queries manually on the swingbench schema, Geert was also able to see this behaviour. So we should also figure out what happens by using acfs. If it is still strange, we should contact Oracle as well. We will see.
If you run swingbench with the preconfigured runbooks, the first bottleneck you find is the cpu. This is due to all the pl/sql in swing bench. So knowing that … the next tests will be Logical IO.
As always, questions, remarks? find me on twitter @vanpupi