Database Reference
In-Depth Information
So what does ORION allow you to do? It's easiest to start off with the way it generates I/O workloads. Internally
ORION uses a two-dimensional matrix depicting small I/O and large I/O requests. Columns in the matrix represent
small I/O requests; rows are large I/O requests. This matrix approach is illustrated in Table
3-3
:
Table 3-3.
The Point Matrix Used Internally by ORION
Type of I/O
# concurrent
small I/Os
...
# concurrent
large I/Os
0
1
2
...
0
Data point
Data point
Data point
...
1
Data point
Data point
Data point
...
2
Data point
Data point
Data point
...
...
...
...
...
Small I/O requests are user-configurable but default to 8k, which equals the default block size of modern Oracle
databases and most of the other databases. Large I/O requests can also be defined as an input parameter to the
benchmark run; they default to 1MB, which is in line with the default maximum size of a single I/O on most platforms.
Benchmarks generate load by increasing the concurrency of outstanding I/O requests, either with or without
additional large I/O requests. For each element in the matrix, ORION records information and presents it later in text
files. To use ORION, you need to pass an argument to the mandatory parameter “run.” It can take the following values:
•
Simple: A simple run which tests random small 8k in isolation, i.e., uses row 0 in the above
matrix: multiple concurrent small I/Os but no large ones. It then runs tests using multiple
concurrent large I/Os, i.e., stays in column 0. It does not combine small and large I/Os.
•
Normal: traverses the whole matrix and tests various combinations of small and large I/Os.
This run can take a while to complete.
•
DSS: Uniquely tests random large I/Os at increasing concurrency, stays in column 0 in the
above matrix.
•
OLTP: tests only small I/Os, stays in row 0 in the above matrix.
•
Advanced: allows you define your own workload by picking rows, columns, or individual data
points in the matrix. Advanced testing is out of scope of this chapter.
There are some concerns whether or not ORION really represents a true database workload. One argument
against ORION is that it does not have to deal with a buffer cache and its maintenance and some other work an active
Oracle instance has to perform. Despite the few downsides to ORION, you should assume that ORION is a good tool,
albeit not 100 percent accurate. It certainly is good enough to get a better understanding of your storage subsystem
when used as a baseline.
Before you can start a benchmark run with ORION, you need to define a set of targets you want to test against.
These are usually LUNs provisioned from the storage array or a directly attached block device, maybe even via PCIe.
The LUNs need to be listed in an input file and terminated with a new line. If you were testing a system with 5 LUNs
for a future ASM disk group “DATA,” the file could have the following contents:
/dev/mapper/asm_data_disk001p1
/dev/mapper/asm_data_disk001p2
/dev/mapper/asm_data_disk001p3
/dev/mapper/asm_data_disk001p4
/dev/mapper/asm_data_disk001p5
Search WWH ::
Custom Search