SLOB 2.5.4 has important fixes to support very large session count testing. Testing with a large number of sessions is generally done in conjunction with enabling SLOB think time. Please see the documentation for more information about testing with SLOB think time. SLOB 2.5.4 has been tested with 12,288 sessions on 8-node RAC clusters (1,536 sessions per RAC instance) with varying think time.
When testing with very large session count, please consider taking advantage of the SLOB 2.5.3 feature of improved SLOB sessions placement as explained here.
Kevin Closson's Blog: Platforms, Databases and Storage 
Hello Kevin,
What’s the reason for setting the default block size to 16k (BLOCK_SZ=${BLOCK_SZ:=16384}?
That’s a *really stupid* bug! My testing environments used the wrong slob.conf so I had BLOCK_SZ=8192 in slob.conf which hid that bug. Thanks for reporting it. I will fix it as soon as possible. In the meantime, feel free to edit runit.sh or set BLOCK_SZ=8192 in slob.conf. The effect of this bug is that you will only be testing 50% of the data you load with setup.sh!
when I give update_pct=50, I expect 50% update and 50% select. But I see ~35% update (write I/O) and rest read. What is the reason for that, How to make read/write 50-50.
It requires some experimentation in your specific environment. Just remember that Oracle Database has to read a block into the SGA buffer pool to process an UPDATE DML command. I googled “slob read write ratio” to see:
Mixed read/write workload: A setting of UPDATE_PCT=20 is often used to simulate a mixed workload typical of OLTP applications, which includes a balance of reads and writes. Because Oracle must first read a block into its cache before it can write to it, an UPDATE_PCT of 100 will still result in roughly a 50/50 mix of reads and writes, not 100% writes.