diff options
Diffstat (limited to 'gemfeed/2018-06-01-realistic-load-testing-with-ioriot-for-linux.md')
| -rw-r--r-- | gemfeed/2018-06-01-realistic-load-testing-with-ioriot-for-linux.md | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/gemfeed/2018-06-01-realistic-load-testing-with-ioriot-for-linux.md b/gemfeed/2018-06-01-realistic-load-testing-with-ioriot-for-linux.md index 4b03f475..3c876f60 100644 --- a/gemfeed/2018-06-01-realistic-load-testing-with-ioriot-for-linux.md +++ b/gemfeed/2018-06-01-realistic-load-testing-with-ioriot-for-linux.md @@ -81,7 +81,7 @@ During recording, ioriot acts as a wrapper and executes all relevant Systemtap c % sudo ioriot -c io.capture ``` -[](./2018-06-01-realistic-load-testing-with-ioriot-for-linux/figure1-ioriot-io-recording.png) +[](./realistic-load-testing-with-ioriot-for-linux/figure1-ioriot-io-recording.png) A Ctrl-C (SIGINT) stops recording prematurely. Otherwise, ioriot terminates itself automatically after 1 hour. Depending on the system load, the output file can grow to several gigabytes. Only metadata is logged, not the read and written data itself. When replaying later, only random data is used. Under certain circumstances, Systemtap may omit some system calls and issue warnings. This is to ensure that Systemtap does not consume too many resources. @@ -105,7 +105,7 @@ The test will most likely want to access existing files. These are files the tes To avoid any damage to the running system, ioreplay only works in special directories. The tool creates a separate subdirectory for each file system mount point (e.g. /, /usr/local, /store/00,...) (here: /.ioriot/TESTNAME, /usr/local/.ioriot/TESTNAME, /store/00/.ioriot/TESTNAME,...). By default, the working directory of ioriot is /usr/local/ioriot/TESTNAME. -[](./2018-06-01-realistic-load-testing-with-ioriot-for-linux/figure2-ioriot-test-preparation.png) +[](./realistic-load-testing-with-ioriot-for-linux/figure2-ioriot-test-preparation.png) You must re-initialize the environment before each run. Data from previous tests will be moved to a trash directory automatically, which can be finally deleted with "sudo ioriot -P". @@ -115,7 +115,7 @@ After initialization, you can replay the log with -r. You can use -R to initiate You can also influence the playback speed: "-s 0" is interpreted as "Playback as fast as possible" and is the default setting. With "-s 1" all operations are performed at original speed. "-s 2" would double the playback speed and "-s 0.5" would halve it. -[](./2018-06-01-realistic-load-testing-with-ioriot-for-linux/figure3-ioriot-replay.png) +[](./realistic-load-testing-with-ioriot-for-linux/figure3-ioriot-replay.png) As an initial test, for example, you could compare the two Linux I/O schedulers CFQ and Deadline and check which scheduler the test runs the fastest. They run the test separately for each scheduler. The following shell loop iterates through all attached block devices of the system and changes their I/O scheduler to the one specified in variable $new_scheduler (in this case either cfq or deadline). Subsequently, all I/O events from the io.replay protocol are played back. At the end, an output file with statistics is generated: @@ -157,13 +157,13 @@ Total time: 1213.00s In any case, you should also set up a time series database, such as Graphite, where the I/O throughput can be plotted. Figures 4 and 5 show the read and write access times of both tests. The break-in makes it clear when the CFQ test ended and the deadline test was started. The reading latency of both tests is similar. Write latency is dramatically improved using the Deadline Scheduler. -[](./2018-06-01-realistic-load-testing-with-ioriot-for-linux/figure4-ioriot-read-latency.png) +[](./realistic-load-testing-with-ioriot-for-linux/figure4-ioriot-read-latency.png) -[](./2018-06-01-realistic-load-testing-with-ioriot-for-linux/figure5-ioriot-write-latency.png) +[](./realistic-load-testing-with-ioriot-for-linux/figure5-ioriot-write-latency.png) You should also take a look at the iostat tool. The iostat screenshot shows the output of iostat -x 10 during a test run. As you can see, a block device is fully loaded with 99% utilization, while all other block devices still have sufficient buffer. This could be an indication of poor data distribution in the storage system and is worth pursuing. It is not uncommon for I/O Riot to reveal software problems. -[](./2018-06-01-realistic-load-testing-with-ioriot-for-linux/figure6-iostat.png) +[](./realistic-load-testing-with-ioriot-for-linux/figure6-iostat.png) ## I/O Riot is Open Source |