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
Kevin Closson's Blog: Platforms, Databases and Storage 
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.
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.
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!
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).
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
Hello I’ve posted a question on OTN regarding these hidden parameters.
Could you please check it and comment it?
I’m testing scaleio performance.
https://community.oracle.com/message/14979086
Thanks,
RobK
I answered in the community.oracle.com thread: https://community.oracle.com/thread/4181670