1 files changed, 8 insertions, 8 deletions

diff --git a/gemfeed/2018-06-01-realistic-load-testing-with-ioriot-for-linux.html b/gemfeed/2018-06-01-realistic-load-testing-with-ioriot-for-linux.html
index 06431f1a..f0b1afb3 100644
--- a/gemfeed/2018-06-01-realistic-load-testing-with-ioriot-for-linux.html
+++ b/gemfeed/2018-06-01-realistic-load-testing-with-ioriot-for-linux.html
@@ -18,7 +18,7 @@
     | \     )|_
    /`\_`>  <_/ \
 jgs\__/'---'\__/
-</pre>
+</pre><br />
 <p class="quote"><i>Published by Paul at 2018-06-01, last updated at 2021-05-08</i></p>
 <h2>Foreword</h2>
 <p>This text first was published in the german IT-Administrator computer Magazine. 3 years have passed since and I decided to publish it on my blog too. </p>
@@ -42,7 +42,7 @@ jgs\__/'---'\__/
 <p>I/O Riot was tested under CentOS 7.2 x86_64. For compiling, the GNU C compiler and Systemtap including kernel debug information are required. Other Linux distributions are theoretically compatible but untested. First of all, you should update the systems involved as follows:</p>
 <pre>
 % sudo yum update
-</pre>
+</pre><br />
 <p>If the kernel is updated, please restart the system. The installation would be done without a restart but this would complicate the installation. The installed kernel version should always correspond to the currently running kernel. You can then install I/O Riot as follows:</p>
 <pre>
 % sudo yum install gcc git systemtap yum-utils kernel-devel-$(uname -r)
@@ -52,27 +52,27 @@ jgs\__/'---'\__/
 % make
 % sudo make install
 % export PATH=$PATH:/opt/ioriot/bin
-</pre>
+</pre><br />
 <p>Note: It is not best practice to install any compilers on production systems. For further information please have a look at the enclosed README.md.</p>
 <h3>Recording of I/O events</h3>
 <p>All I/O events are kernel related. If a process wants to perform an I/O operation, such as opening a file, it must inform the kernel of this by a system call (short syscall). I/O Riot relies on the Systemtap tool to record I/O syscalls. Systemtap, available for all popular Linux distributions, helps you to take a look at the running kernel in productive environments, which makes it predestined to monitor all I/O-relevant Linux syscalls and log them to a file. Other tools, such as strace, are not an alternative because they slow down the system too much.</p>
 <p>During recording, ioriot acts as a wrapper and executes all relevant Systemtap commands for you. Use the following command to log all events to io.capture:</p>
 <pre>
 % sudo ioriot -c io.capture
-</pre>
+</pre><br />
 <a href="./2018-06-01-realistic-load-testing-with-ioriot-for-linux/figure1-ioriot-io-recording.png"><img alt="Screenshot I/O recording" title="Screenshot I/O recording" src="./2018-06-01-realistic-load-testing-with-ioriot-for-linux/figure1-ioriot-io-recording.png" /></a><br />
 <p>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.</p>
 <h3>Test preparation</h3>
 <p>Then copy io.capture to a test system. The log also contains all accesses to the pseudo file systems devfs, sysfs and procfs. This makes little sense, which is why you must first generate a cleaned and playable version io.replay from io.capture as follows:</p>
 <pre>
 % sudo ioriot -c io.capture -r io.replay -u $USER -n TESTNAME
-</pre>
+</pre><br />
 <p>The parameter -n allows you to assign a freely selectable test name. An arbitrary system user under which the test is to be played is specified via paramater -u.</p>
 <h3>Test Initialization</h3>
 <p>The test will most likely want to access existing files. These are files the test wants to read but does not create by itself. The existence of these must be ensured before the test. You can do this as follows:</p>
 <pre>
 % sudo ioriot -i io.replay
-</pre>
+</pre><br />
 <p>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.</p>
 <a href="./2018-06-01-realistic-load-testing-with-ioriot-for-linux/figure2-ioriot-test-preparation.png"><img alt="Screenshot test preparation" title="Screenshot test preparation" src="./2018-06-01-realistic-load-testing-with-ioriot-for-linux/figure2-ioriot-test-preparation.png" /></a><br />
 <p>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".</p>
@@ -92,7 +92,7 @@ done
    echo $new_scheduler | sudo tee $scheduler
 done
 % sudo ioriot -R io.replay -S deadline.txt
-</pre>
+</pre><br />
 <p>According to the results, the test could run 940 seconds faster with Deadline Scheduler:</p>
 <pre>
 % cat cfq.txt
@@ -113,7 +113,7 @@ Performed ioops: 218624596
 Average ioops/s: 180234.62
 Time ahead: 2392s
 Total time: 1213.00s
-</pre>
+</pre><br />
 <p>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.</p>
 <a href="./2018-06-01-realistic-load-testing-with-ioriot-for-linux/figure4-ioriot-read-latency.png"><img alt="Graphite visualization of the mean read access times in ms with CFQ and Deadline Scheduler." title="Graphite visualization of the mean read access times in ms with CFQ and Deadline Scheduler." src="./2018-06-01-realistic-load-testing-with-ioriot-for-linux/figure4-ioriot-read-latency.png" /></a><br />
 <a href="./2018-06-01-realistic-load-testing-with-ioriot-for-linux/figure5-ioriot-write-latency.png"><img alt="Graphite visualization of the average write access times in ms with CFQ and Deadline Scheduler." title="Graphite visualization of the average write access times in ms with CFQ and Deadline Scheduler." src="./2018-06-01-realistic-load-testing-with-ioriot-for-linux/figure5-ioriot-write-latency.png" /></a><br />