My SLOB IO Testing Index

Martin Berger suggested to create this page to keep track of blog posts related SLOB IO testing. Here it is Martin ;)

References to my SLOB testing related blog posts:

1. ALL Pythian blog posts with Post Tag #SLOB
2. My First Experience Running SLOB – Status Update 1 – or why I started the testing
3. Status Update 2 (first results) – first conclusions Orion vs SLOB – 1:0
4. Don’t repeat my errors (AWR) – explains the AWR issue that can screw up results
5. Final results – ORION vs SLOB - results
6. ORION vs SLOB - 2:0 – final post and conclusions
7. SLOB on steroids – Part 1
8. SLOB LinkedIn Group

If you are seriously interested to get a good understanding of your IO subsystem performance characteristics then one of the tools that you may consider for putting your system IO on stress is SLOB. See Introducing SLOB – The Silly Little Oracle Benchmark from  Kevin Closson. I did and I learned a lot on my way. A bit of warning from my side – you should be ready to invest a bit of time (days in my case) to make sure that the results you are getting are reliable.

As SLOB takes the IO testing on Oracle Instance level you need to watch for several things before you declare official testing results. My suggestion is – don’t take any results for granted. You need to assess those before stating you are done. There goes my list.

NOTE: This list is valid for Physical IO testing only as opposite to LIO or Oracle Physical IO stack testing (cached IO) and based on my personal experience. Your case/configuration may be different.

• Make data cache as small as possible. Don’t worry about any concurrency issues before you hit them. I set db_cache_size=12M and it didn’t give me any concurrency problems even with 128 readers test. Details are here.
• Make sure that the SQL used by SLOB does what it intended to do – make a lot of “db file sequential read” based IOs. Newer Oracle versions bring some optimizations in the area therefore you should be carefully assessing results before making them available to others.  You will find some recommendations on how to avoid some of 11.2.0.3 version optimizations in this blog post (see hidden init.ora parameters).
• Run SLOB several times and make sure that the results you are getting are consistent. Otherwise question those. One thing that I found during my tests was the fact that earlier versions of SLOB had a “bug” generating awr.txt reports. AWR didn’t cover all my tests’ time. For details and solution see “My First Experience Running SLOB – Don’t repeat my errors (AWR)“
• Keep in mind that Inner and Outer areas of HDDs have different performance characteristics. If your goal is to test your real application IO performance then think about what disk areas your application data will be located and try your best to locate SLOB data the same way (no blog post here as of now).
• Don’t put  all your test data close to each other. If HDDs in your system are big than SLOB puts test data in the same/close area. Oracle doesn’t need to move HDDs’ heads to read the data that much in this case. It rarely happens in real world configurations. If you do use default SLOB data load tests’ results may not be close to your application’s IO load (no blog post here as of now).
• Switch ALL other load on your system if possible. If you seriously want to get reliable and consistent results you should switch off all the other stuff that may impact testing results. Even if you created an empty database (as I did) you should put some efforts into switching off some IO impacting processes. The following are in my list as of now: Backups, Oracle Automatic Jobs, All other Scheduler and DBA_JOBS tasks, Resource manager(no blog post here as of now).
• Avoid any caches. If you want to test real Physical IO performance you should make sure that no data is returned from any kind of caches. Someone would say: Hey we do have caches in day to day operations, why should we switch those off? Well sit back for a moment and ask yourself what you are trying to achieve by those tests and read the note at the beginning of this list once again. As a rule of thumb any IOs served in less than 5ms have a good chance to be returned from some sort of cache (unless you are using SSDs). Try your best to verify it and adjust your test accordantly.
• Switch on 10046 trace for some of the SLOB sessions to verify the results. The AWR.txt report gives you the average numbers only. This means there is no way to verify what percentage of your IO requests are returned from caches. In my case AWR reported 5ms average IO response for “db file sequential read” events. This seemed to be a reasonable figure. However luckily enough I switched on 10046 trace for some of the SLOB sessions. Using Method-R MrTools I easily found that 51% of all IOs for the test served in 0.1ms time. Most of you know what does that mean (IOs has been served from cache). My 5ms response time results weren’t reliable after I verified and I had to redo the test.
• Added on 2012.05.21: Make sure that “db file sequential read” is the only IO related event in the AWR TOP 5 events. If htere are other IO related events then most probably SLOB test didn’t work well. As an example of other IO related events I would mention “db file parallel read”. If you see it in your SLOB AWR report you should investigate why and redo the test.

I think I will stop here for now. It seems I gave you enough material to think and work on. I hope that my work will let some of you get back to your SLOB testing. I will try my best to add some more details to this post later on as time permits.

If you like my work please do me a favour: let me know about any other SLOB PHYSICAL IO testing related blog posts in comments of this blog post :)

Good luck with your testing,

Yury

PS My current impression after 3+ days in SLOB testing is – It takes a lot of time and fine tuning to get a reliable PIO testing results. Orion on the other hand just test Physical IO providing pessimistic results straight away.