Estimating IO throughput at your cloud deployment

Estimating the IO maximum throughput is the big question when you are going to production either with Docker on-premise deployment or at a cloud provider.

When I telling IO throughput We are thinking in shared storage for your RDBMS deployment, ES cluster or whatever your data will persist over the life-time of the container which by definition is ephemeral.

To do that I prepared an small (266Mb) Docker image using Oracle Orion tool, this tool is special designed for Oracle RDBMS but can be used to get a consistent value of your IO performance against different scenario, read only/ read write/raid/etc.

Docker image is created either from Oracle DBMS official Docker image or using Oracle Database EE available at Docker store (require login and accept term & conditions). Here a Dockerfile for building Orion image from your local RDBMS image:

to build your Orion image using Oracle RBMS local image do:

$ docker build -t oracle/orion: .
.... build output here ....
$ docker image ls |grep orion
oracle/orion 188dbf1878e9 3 days ago 266MB

A Dockerfile for building your image from Oracle RDBMS EE at look like:

before building your image, first you have to login at Docker Store Accept Term & License for using Oracle RDBMS EE image and pull the image following the instructions

finally build your Orion image using:

$ docker build -t oracle/orion: .
.... build output here ....
$ docker image ls |grep orion
oracle/orion 188dbf1878e9 3 days ago 266MB

and thats all here an example running Orion tool using a local disk storage:

$ dd if=/dev/zero of=/home/data/tmp/test.file bs=1G count=1
$ cat /home/data/tmp/firsttest.lun
$ docker run --rm -v /home/data/tmp:/home oracle/orion: /usr/lib/oracle/12.2/client64/bin/orion -run simple -testname firsttest -hugenotneeded
ORION: ORacle IO Numbers — Version
Calibration will take approximately 9 minutes.
Using a large value for -cache_size may take longer.
Maximum Large MBPS=262.00 @ Small=0 and Large=2
Maximum Small IOPS=21680 @ Small=5 and Large=0
Small Read Latency: avg=229.219 us, min=142.356 us, max=20530.369 us, std dev=171.852 us @ Small=5 and Large=0
Minimum Small Latency=191.948 usecs @ Small=1 and Large=0
Small Read Latency: avg=191.948 us, min=133.997 us, max=13625.097 us, std dev=89.075 us @ Small=1 and Large=0
Small Read / Write Latency Histogram @ Small=1 and Large=0
Latency: # of IOs (read) # of IOs (write)
0–128 us: 0 ( 0.00%) 0 ( 0.00%)
128–256 us: 299022 ( 96.76%) 0 ( 0.00%)
256–512 us: 9538 ( 99.84%) 0 ( 0.00%)
512–1024 us: 261 ( 99.93%) 0 ( 0.00%)
1024–2048 us: 104 ( 99.96%) 0 ( 0.00%)
2048–4096 us: 76 ( 99.99%) 0 ( 0.00%)
4096–8192 us: 41 (100.00%) 0 ( 0.00%)
8192–16384 us: 2 (100.00%) 0 ( 0.00%)
16384–268435456 us: 0 (100.00%) 0 ( 0.00%)

Note that I am creating a 1Gb file named test.file at /home/data/tmp directory which is mounted at the container space /home, this test file is referenced into /home/data/tmp/firsttest.lun configuration file. If you need more information about Orion samples look like this blog post.

Here a sample output running with Docker Swarm and a remote Storage exported as NFS from a QNap NAS storage, docker-compose.yml stack file:

Here output from Portainer.IO console with the service execution:

Note that read performance MBPS downs from 262 in my notebook with SSD disk to 60.65 using a NAS storage connected using a Gb switch and with another simultaneous workload, here another test using a Linux server as NFS storage with a Raid 0 disk configuration and 1Gbps network connection

despite different configuration We see that the expected IO performance are too different and basically are affected for disks and network resources, next step is to check these values at Oracle Cloud. Feel free to put into comments section your result at any public cloud.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store