Multi-test (Emulating a Busy Server)

When you need to understand how a storage subsystem behaves under realistic multitasking load, a single sequential read or write test will not cut it. The multi-test utility described here launches multiple threads that each perform different types of IO (sequential reads, random writes, mixed workloads) simultaneously, giving you a much closer picture of what a busy production server actually experiences.

How It Works

The script operates in several distinct states, each representing a different IO pattern:

• Sequential read - large block reads in order, simulating log replay or backup.
• Sequential write - large block writes in order, simulating data ingestion.
• Random read - small, scattered reads, simulating OLTP-style lookups.
• Random write - small, scattered writes, simulating transaction commits.
• Mixed workload - a combination of the above running concurrently.

Between each state the script invalidates the OS page cache (via echo 3 > /proc/sys/vm/drop_caches on Linux or the equivalent on your platform) and uses direct IO (O_DIRECT / O_SYNC) so that results reflect actual disk throughput rather than memory-backed reads.

Why Direct IO and Cache Invalidation Matter

Without these two safeguards, a “disk” benchmark is really a memory benchmark. The page cache will happily serve repeated reads from RAM, and the write-back cache will absorb writes and flush them later, both of which mask the true latency and throughput of the underlying storage. By bypassing the cache and forcing synchronous completion, the test isolates the storage layer.

Running the Test

The attached Perl script is self-contained. On a Linux host with the perl interpreter and the threads module available, you can invoke it directly:

perl multitest.pl --devices /dev/sda --iterations 5 --threads 8

Adjust the device list, iteration count, and thread count to match the workload you want to emulate. The script prints per-state throughput (MB/s), IOPS, and average latency so you can compare states side by side.

Interpreting Results

• A large gap between sequential and random throughput is normal and expected on spinning media; on SSDs the gap should be much smaller.
• If random-write IOPS drops sharply as thread count increases, you are likely hitting a controller or queue-depth bottleneck.
• Compare results across states to identify which workload pattern your production server stresses most, then focus tuning (queue depth, scheduler, RAID level) on that pattern.

Attachment

📎 Download multitest.pl

• How-To

• Perl
• SysAdmin
• Bash