Simple SLOB Init.ora Parameter File For Read IOPS Testing

This is just a quick blog entry to show the very simple init.ora parameter file I use to stress simple read IOPS testing with SLOB.  On 2s16c32t E5-2600 servers attached to very fast storage this init.ora parameter delivers on the order of 275,000 physical IOPS with 64 SLOB sessions.

I’ll post an init.ora that I use for the REDO model and DBWR testing as soon as possible.

Thanks to Yury for the recommended hidden init.ora parameters to boost the ratio of db file sequential reads.

Additional information can be found here: README file.

Here is the init.ora:

UNDO_MANAGEMENT=AUTO
db_block_size = 8192
db_files = 20000
processes = 500
shared_pool_size = 5000M
db_cache_size=128M
filesystemio_options=setall
parallel_max_servers=0
_db_block_prefetch_limit=0
_db_block_prefetch_quota=0
_db_file_noncontig_mblock_read_count=0
log_buffer=134217728
pga_aggregate_target=1G

7 Responses to “Simple SLOB Init.ora Parameter File For Read IOPS Testing”


  1. 1 Martin Berger (@martinberx) June 10, 2012 at 9:29 pm

    I had a reasonable amount of “simulator hash latch” / “simulator lru latch” while playing with LIO tests. According to http://blog.tanelpoder.com/2009/09/13/kgl-simulator-shared-pool-simulator-and-buffer-cache-simulator-what-are-these/ I set
    db_cache_advice=off (default=on)
    in the init.ora – Now these waits are gone.

  2. 2 Matt June 12, 2012 at 4:21 pm

    I have not tried a 10M SGA yet. I will try that later this evening time allowing.

    To echo from several of your posts. You have to have several tools for measuring performance. We use SLOB as one them, as a baseline we know it will deliver on server platform x and array configuration y. Being able run this “same” test in different platforms it allows us to develop a profile.

    We find ourselves using IO calibrate more often than Orion but we use them both so that we can add to the overall profile of the ecosystem.

  3. 3 FC June 18, 2012 at 4:51 am

    Hello,

    Setting a small cache_size will increase the number of PIO, that’s a fair objective. But the other options (which I don’t know so it might be a useless message) seems to change the way physical IOs are done.

    By starting to use hidden parameter to boost the number of LIOs, aren’t you getting away from your first goal ? And by excessively customizing it to get higher results starting to have an “unrealistic platform performance measurement tools”, excepted the tool is fine, but the platform is not?
    I mean, if i’m using a database in production with a number of parameters, when I’m testing with SLOB or any other thing, for sure I want to see how _my system_ performs, with my settings no?

    Cheers!

    • 4 kevinclosson June 18, 2012 at 7:37 am

      Hello FC,

      The hidden parameters I use in this example init.ora are to neutralize a recent Oracle optimization that substitutes db file sequential read with multiblock reads in some situations. We want SLOB to be a single block rand read engine driven by SQL. These parameters do not (in my testing) affect LIO. If anyone has measured otherwise it would be helpful if they would point it out.

      If using SLOB to measure maximum demonstrable platform capability for Oracle I/O then use whatever init.ora it takes to achieve that goal. After you have that measurement then switch to setting that mimic what you have to use in production so see if it is different.

      P.S., Say “Hi” to Eric G. for me (if you work in the same area as him).

  4. 5 FC July 2, 2012 at 7:18 am

    Hi,

    You have the hello from Eric :) (for some days actually)
    Ok, thank you for response. It’s very clear and sounds obvious now.

    Following this comment about the size of the tables:

    http://www.pythian.com/news/33299/my-slob-io-testing-index/#comment-797183

    Do you have any guideline, or feedback?
    I mean, when you are using SLOB to compare the speed of SSD, size doesn’t matter I agree because you have no cache. But when using , in our case, a NAS with hard drives and some caching (32GB of memory in my case) then, the size of tables has to be taken into account. Because at some point, increasing the number of SLOB sessions would just make the tables’sizes bigger than our NAS memory. Which decreases a lot the performance, but it is not really due to the number of PIO per second, but rather to the size of the dataset we are working on.
    Which could lead to different slopes
    -1/everything fits in the cache of the NAS
    -2/And then suddenly, as we are increasing the number of SLOB sessions, it no longer fits in the cache. So in a hidden way, we are actually changing two parameters at the same time: number of SLOB sessions + reading from the hard drives

    I don’t know if what I mean is very clear. :-S

    Cheers!

    FC


  1. 1 Introducing SLOB – The Silly Little Oracle Benchmark « Kevin Closson's Blog: Platforms, Databases and Storage Trackback on August 31, 2012 at 9:22 am
  2. 2 Collection of links, tips and tools for running SLOB | Pardy DBA Trackback on February 15, 2013 at 5:53 pm

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




EMC Employee Disclaimer

The opinions and interests expressed on EMC employee blogs are the employees' own and do not necessarily represent EMC's positions, strategies or views. EMC makes no representation or warranties about employee blogs or the accuracy or reliability of such blogs. When you access employee blogs, even though they may contain the EMC logo and content regarding EMC products and services, employee blogs are independent of EMC and EMC does not control their content or operation. In addition, a link to a blog does not mean that EMC endorses that blog or has responsibility for its content or use.

This disclaimer was put into place on March 23, 2011.

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 2,027 other followers

Oracle ACE Program Status

Click It

website metrics

Fond Memories

Copyright

All content is © Kevin Closson and "Kevin Closson's Blog: Platforms, Databases, and Storage", 2006-2013. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Kevin Closson and Kevin Closson's Blog: Platforms, Databases, and Storage with appropriate and specific direction to the original content.

Follow

Get every new post delivered to your Inbox.

Join 2,027 other followers

%d bloggers like this: