Simulating and testing I/O performances with ORION

---

Since Oracle 11.2, Oracle provides ORION in the RDBMS binaries (in ${ORACLE_HOME}/bin). ORION – ORacle Input Output Numbers – is an I/O calibration tool allowing to simulating and testing I/O performances an Oracle database would be confronted with. ORION basically supports four kinds of database activities based on either small or large I/O. ORION can, as any respectable I/O simulation tool, generate an adapted workload using a given percentage of reads and write operations.

OLTP activity

ORION can simulate OLTP systems typically generating small random read and write activities. The I/O sizes are equivalent to the database block size (usually 8KB) and the application analyzes the following database I/O KPIs:

• IOPS (I/O Per seconds)
• I/O latency average (I/O turn-around time) per request

The first part of the “simple” run (option -run simple) simulates this kind of workload (only with read). ORION also provides an OLTP-like (option -run oltp) scheme in which you can specify the percentage of writes.

Large sequential read activity

ORION can also simulate large sequential I/Os which can be caused by database exports (through data pump), RMAN backup, or of course a data warehouse environment. In this case, large I/Os will be simulated (1 MB per default). These types of applications or procedures are processing large amount of data and the important KPI is the throughput in MBps (MB per seconds). In this case, ORION can simulate large I/O read or write streams.

This kind of workload requires the option “-type seq” to be set in order to simulate large sequential I/Os. The “mixed” workload through a workload “matrix” might also be used, see below.

Large random read activity

Large random I/O is another kind of workload ORION can simulate. The tool therefore simulates large I/Os stripped over several disk, allowing to simulate parallel activities. In this case, multiple large I/O streams are started against the available disks.

The “dss” run (option -run dss) simulates this type of activity.

Mixed Workload

Finally, the mixed workload allows to simulate together small random I/Os and large sequential or random I/Os. Of course, this workload type is useful for OLTP systems confronted with performance issues caused by online backups for instance. A percentage of writes can also be simulated during these tests.

The “normal” run (option -run normal) simulates mixed activity of the sort, but of course the “matrix” workload is perfectly adapted to this simulation.

ORION has one major drawback: It cannot perform a filesystem performance analysis. It was only designed to be started against devices. We tested it on raw devices, since they are not buffered as block devices.
ORION can be used to test performances of disks, luns, SAN, DAS, or even certain type of NAS (we have not tested this so far).

In order to prepare the test, first of all we have to purge the raw device(s) on which we will generate the load:

A file containing the devices on which the load will be generated on must be created (testname.lun):

ORION offers a very interesting feature. Since most of the SAN have caches, there is a risk of being impacted by “cache hits” during the I/O load tests. For this purpose ORION will generate random I/O which cannot be re-used by the test in order to full-fill the SAN cache and avoid the “I/O cache hit” effect. ORION even offers the possibility to set the size of the SAN cache in order to be quite precise. If this parameter is not set, ORION fulfills per default during 2 minutes the cache with useless I/O.

In order to run a so called “simple test”, the “-run simple” option can be used. Take care that this test scheme will not mix up several types of workload. Small random I/O will be performed separated from large random and sequential I/Os. Moreover, only reads are simulated in this test scheme. Note that ORION refuses to start without a fully qualified path:

Once started as expected, the following output is generated:

- Orion output 1 -

The output represented above shows:

• Maximum MBPS (MB per seconds): 101
• Maximum IOPS (I/O per seconds): 635
• I/O latencies information

The following files are produced:

These files contain useful information about I/O performances and have the following structure:

• Lines represent large I/O load levels (number of outstanding large I/Os)
• Columns represent small I/O load levels (number of outstanding small I/Os)

Since there is no small/large I/O mix up in the “simple” test, the tables stored in the generated files will have only one dimension (either one column or one row).

The file containing the throughput performances measured in MBPS (MB per second) has the following layout:

# cat simpletest_20110201_1551_mbps.csv

This comma-separated-value file contains the rates sustained by large I/Os in MBps. Each value corresponds to a data point test that used a fixed number of outstanding small and large I/Os. The number of outstanding small I/Os for a value is specified by its column header in the first row. The number of outstanding large I/Os for a value is specified by its row header in the first column.

Large/Small,      0,      1,      2,      3,      4,      5

1,  56.41
2, 101.82

In our example, the highest throughput is 101 MB/s. This value is rather weak for a SAN. The faster SANs reach up to 200 or 300 MB/s.
The I/O latency can be found in the following .csv file (simpletest_20110201_1551_lat.csv):

# cat simpletest_20110201_1551_lat.csv

 

This comma-separated-value file contains the average latency sustained by small I/Os in microseconds. Each value corresponds to a data point test that used a fixed number of outstanding small and large I/Os. The number of outstanding small I/Os for a value is specified by its column header in the first row. The number of outstanding large I/Os for a value is specified by its row header in the first column.

Large/Small,      1,      2,      3,      4,      5
0, 9478.83, 8590.16, 8097.65, 8089.16, 7866.98
1
2

The measured latency is located between 7.8 to 9.4 ms. According to several forums, the accepted I/O latency should be below 10ms. The average latency is indeed below 10ms, however 12410 (about one third) small I/Os had a latency between 8 and 16ms (see above – Orion output 1 -).

To simulate mixed up I/O workload (small random, large random, and large sequential), you have to use the following command and perform a “normal” test:

# $ORACLE_HOME/bin/orion -run normal -testname normaltest

This command might fail after a while with the following output:

This issue is documented in the bug 9104898: “ORION FAILS WITH ORA-27061: WAITING FOR ASYNC I/OS FAILED”. According to the bug description, ORION has difficulties with Large I/Os on Red Hat Enterprise Linux Sever 5. The bug is currently under investigation at Oracle development.

It is also possible to define exactly how many outstanding small and large I/O you want ORION to simulate in parallel. For this purpose the “matrix” test should be used. In this case you specify the maximum number of outstanding small (-num_small) and large (-num_large) I/Os. You can even specify the size for the large I/O (depending on your infrastructure and future database settings):

To simulate OLTP activities with about 20% of writes, the following parameters might be used:

You will find the technical specifications concerning the hardware and operating system below:

As a Summary

Considering all advantages and drawbacks, ORION is quite an interesting tool. However, as mentioned by several experts, this tool is mainly useful in case you are at the beginning of a project and have full access to the disk/LUN configuration. It is definitively not a good idea to overwrite some LUNs on the production environment. ORION also allows realizing test schemes that are perfectly fitted to the database behavior and offer a robust framework to compare storage vendors and storage infrastructures.

---

Article Number: 324
Posted: Wed, Jul 25, 2018 1:19 PM
Last Updated: Wed, Jul 25, 2018 1:19 PM

Online URL: http://kb.ictbanking.net/article.php?id=324