Oaktable World 2014 Kevin Closson: SLOB – For More Than I/O!

SLOB Topics for
Oaktable World 2014
Kevin Closson
Chief Performance Architect
© Copyright 2014 EMC Corporation. All rights reserved. 1

xtremio.com/slob

XtremIO
#1 All-Flash Array in the Market
>$100,000,000 <6 months >40PB sold

Agenda
Ÿ The obvious things you can do with SLOB
Ÿ SLOB without physical I/O?
Ÿ SLOB for Oracle Database 12c In-Memory Option?
Ÿ SLOB for Oracle Multitenant?
Ÿ SLOB to test Oracle Database contention?
Ÿ A peek: Testing 11g on Windows 2012 with SLOB

Typical Platform Testing
With SLOB

..but first, quick SLOB
fundamentals...

SLOB Fundamentals
Ÿ Single design center
– Maximum SQL execution with minimum CPU utilization
– Maximum physical I/O per unit of DB CPU
Ÿ No application contention
– Schema per session
– Single row per block
– 100% random data access

SLOB Fundamentals
Ÿ Predictable and Repeatable
– Results vary less than 3% in the worst case. Generally
1-2% variation
– Semaphore trigger. Timed-completion or fixed SQL
execution count
– SELECT/UPDATE workload. Tables never need reloaded,
single index never needs maintenance

SLOB Fundamentals
Ÿ Predictable and Repeatable
– Synchronous reads
▪ Key Performance Metrics (Executions/sec, PIOPS, etc) directly tied to
I/O service times

SLOB Fundamentals
Ÿ Simple
– All you need
▪ A tablespace to store the SLOB schemas
▪ Enough storage to store ~4:1 ratio of SLOB data to db_cache_size
— Example: 1GB db_cache_size, 32 Sessions, for 4GB use: slob.conf->SCALE=16384
— 16384 * 8192 * 32 == 4GB
▪ Connection by bequeath or SQL*Net

SLOB Fundamentals
Ÿ SLOB is a Linux kit, not ported
– Use Oracle client on Linux
▪ Small physical or virtual as the driver to test Windows, AIX, Solaris,
etc
▪ The client does not require CPU during test execution. It’s 100%
foreground PL/SQL

Testing Physical IOPS
With SLOB
Examples based on
EMC XtremIO

Single Host 2s16c32t Redo Payload vs LGWR Write Latency
- Tip: Tweak SLOB/procedure.sql

Single Host 2s16c32t Redo Payload vs Random Read Latency

Cached SLOB

SLOB: slob.sql

Cached SLOB – Study CPU Scalability
2s16c32t E5-2600
5215
3020
SQL EXECUTIONS/Second
24397
34150
41657
49059
55820
60000
50000
40000
30000
20000
10000
0
0 5 10 15 20 25 30 35 40 45
EXECUTES

2s16c32t E5-2600
1341608
776967
LIOPS
10723697
8791012
6280211
12629035
14369615
16000000
14000000
12000000
10000000
8000000
6000000
4000000
2000000
0
0 5 10 15 20 25 30 35 40 45
LIOPS

2s16c32t E5-2600

Cached SLOB
Focus on Intel SMT

Understand Intel SMT

Perf(1) top - skinny.sql

Perf(1) top – fat.sql

2-socket x86 server performance in the last decade
• With CPU threading
skinny.sql and fat.sql are oil
and water as skinny forces
fat to run on a thread ==
starvation since fat stalls
less (see SQL)
• Same number of “noise”
sessions
• Top case N fat.sql
• Bottom case N skinny.sql
+ 1 fat.sql.

In-Memory Column Store

SLOB – A Focus on In-Memory Database
Ÿ Study OLTP / In-Memory Database Option co-hosting
– In-memory cache population (ingest) rates
– Think “data flow”. Who is a producer and who is a
consumer
▪ inmemory_max_populate_servers and PQO slaves
– Co-hosted with OLTP

Top(1) – In-Memory Database Option

Multitenant Oracle

SLOB – A Focus on Oracle Multitenant
Ÿ Use SLOB to study Oracle Multitenant
Ÿ What better way to understand a simple premise
than to rely on a simple, predictable workload and
test kit?

Ÿ http://www.oracle.com/technetwork/database/multitenant/
learn-more/oraclemultitenantt5-8-final-2185108.pdf, pg 23:
“In Oracle Multitenant, great savings in CPU consumption arise from the sharing of
background processes among databases, which can significantly reduce the amount of
cores needed to support a given number of databases. “
Ÿ Hold it. To achieve great savings in CPU consumption, doesn’t
that mean we must all accept the notion that background
processing consumes a significant amount of CPU bandwidth?

Ÿ Background CPU
– Scrutinize with SLOB. Know your platform. Now your costs and rates.
– We are looking at BG behavior so this is UPDATE intensive SLOB
– 2s20c40t E5-2690v2 host.
– This is a single database!

Ÿ Testing to further understand a simple assertion.
Ÿ The assertion:
– Consolidating from multiple databases/instances into a
single Oracle Multitenant deployment significantly reduces
CPU overhead due to shared background processing

Multitenant – Huge CPU savings?
Simple assertion, simple baseline?

Ÿ Should be simple enough, right?
– SLOB – Simple to use, simple to understand.
▪ 40 simple schema users with zero data sharing – simple workload
▪ 40 databases each with
— A single SLOB session
— slob.conf->SCALE=668734 (5GB 100% randomly visited active data set)
— slob.conf->UPDATE_PCT=25 (SQL mix 75% SELECT, 25% UPDATE)
— Simple init.ora (next slide)
— slob.conf->WORK_LOOP=100000
— Test on a 2s20c40t E5-2690v2 server
Ÿ The metric is job completion – fixed workload.

Ÿ The metric is job completion – fixed workload.
Ÿ Which model pushes through 4,000,000 SQL
executions faster?

Testing Database
Contention
With SLOB?

SLOB – Testing Database Contention
Ÿ slob.conf->SHARED_DATA_MODULUS

Oaktable World 2014 Kevin Closson: SLOB – For More Than I/O!

Oaktable World 2014 Kevin Closson: SLOB – For More Than I/O!

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Oaktable World 2014 Kevin Closson: SLOB – For More Than I/O!

Similar to Oaktable World 2014 Kevin Closson: SLOB – For More Than I/O! (20)

More from Kyle Hailey

More from Kyle Hailey (20)

Recently uploaded

Recently uploaded (20)

Oaktable World 2014 Kevin Closson: SLOB – For More Than I/O!