Random IOPS vs. Sequential IOPS, and How to Read Benchmark Results
公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13
結論
The difference between Random and Sequential is the continuity of access position. On HDD, seek time and rotational latency add up, so the gap between Random and Sequential spans orders of magnitude; on SSD/NVMe, the gap shrinks dramatically but does not disappear (for writes, garbage collection and write amplification add to it as well). And an IOPS figure cannot be compared unless I/O size, queue depth, read/write ratio, and whether direct I/O is used are all stated. When reading a benchmark result, first check whether these four conditions are explicit.
この文書の適用条件
| 対象製品 | Storage in general (HDD / SATA SSD / NVMe SSD / network-attached storage) |
|---|---|
| 確認バージョン | fio 3.x, sysstat (iostat), nvme-cli, Linux (based on the public specification as of 2026-08-13) |
| 適用環境 | On-premises, EC2, Azure VM |
| 必要権限 | fio requires access to the target file/device (root if targeting a device directly). `nvme list` may require root |
| 実行影響 | fio generates I/O load. iostat, lsblk, and nvme list are read-only |
| 再起動 | Not required |
| 最終検証日 | 2026-08-13 |
そのまま実行できるコマンド
- 対象
- Linux + fio 3.x
- 権限
- Read/write access to the target file (root if targeting a device directly)
- 変更作業
- None (read-only), but it generates I/O load
- Production実行
- Not recommended. Run it in a test environment, or against storage not shared with production
# 対象: Linux + fio 3.x
# 権限: 対象ファイルへの読み取り権限（デバイス直接指定なら root）
# 変更作業: なし（読み取りのみ）だが実行中は他処理の I/O 性能に影響する
# Production 実行: 非推奨。検証環境で実行すること
fio --name=rand_read_4k \
--filename=/mnt/testdir/fio_testfile \
--size=64G \
--rw=randread \
--bs=4k \
--ioengine=libaio \
--direct=1 \
--iodepth=32 \
--numjobs=4 \
--runtime=300 \
--time_based \
--ramp_time=30 \
--group_reporting`--ramp_time=30` excludes the first 30 seconds from the tally, letting you exclude cache warm-up or the scheduler settling in. Changing `--iodepth` and `--numjobs` changes the numbers significantly. Don't look at a single figure — measure at several points with different iodepth values.
- 対象
- Linux + fio 3.x
- 権限
- Read access to the target file
- 変更作業
- None (read-only), but it generates I/O load
- Production実行
- Not recommended. Run it in a test environment
# 対象: Linux + fio 3.x
# 権限: 対象ファイルへの読み取り権限
# 変更作業: なし（読み取りのみ）だが I/O 帯域を占有する
# Production 実行: 非推奨。検証環境で実行すること
fio --name=seq_read_1m \
--filename=/mnt/testdir/fio_testfile \
--size=64G \
--rw=read \
--bs=1M \
--ioengine=libaio \
--direct=1 \
--iodepth=8 \
--numjobs=1 \
--runtime=300 \
--time_based \
--group_reportingFor sequential access, look at bandwidth (BW) rather than IOPS. Since the I/O size is large, the IOPS value comes out small — this does not mean it is slow. Keeping in mind that IOPS times block size equals bandwidth helps avoid misreading this.
- 対象
- Linux + fio 3.x
- 権限
- Read/write access to the target file
- 変更作業
- Yes (writes to the test file)
- Production実行
- Do not run this. Since it involves writes, use a dedicated test area
# 対象: Linux + fio 3.x
# 権限: 対象ファイルへの読み書き権限
# 変更作業: あり（テストファイルに書き込む。既存データを指定しないこと）
# Production 実行: 不可。専用の検証領域でのみ実行すること
fio --name=rand_rw_70_30 \
--filename=/mnt/testdir/fio_testfile \
--size=64G \
--rw=randrw \
--rwmixread=70 \
--bs=8k \
--ioengine=libaio \
--direct=1 \
--iodepth=32 \
--numjobs=4 \
--runtime=600 \
--time_based \
--ramp_time=60 \
--group_reportingFor a measurement that includes writes, run it long enough. On SSD, a short run only shows values from when free space is plentiful, missing the steady state once garbage collection kicks in. Always point `--filename` at a dedicated test file — never at an existing data file.
- 対象
- Linux (sysstat / nvme-cli)
- 権限
- Regular user (nvme list may require root)
- 変更作業
- None (read-only)
- Production実行
- Possible
# 対象: Linux（sysstat / nvme-cli）
# 権限: 一般ユーザー（nvme list は root が必要な場合がある）
# 変更作業: なし（参照のみ）
# Production 実行: 可能
lsblk -o NAME,SIZE,TYPE,ROTA,MOUNTPOINT,MODEL
sudo nvme list
iostat -x 1 10`lsblk`'s `ROTA` shows whether it's rotating media (1 = rotational). In `iostat -x`, `r/s`/`w/s` is measured IOPS, `rareq-sz`/`wareq-sz` is average I/O size, `r_await`/`w_await` is latency, and `aqu-sz` is average queue length. Use this to understand what conditions the real workload is actually running under before reading a benchmark result.
結果の読み方
| 列 | 意味 | 確認するポイント |
|---|---|---|
| fio: IOPS | I/O completions per second | Cannot be compared against another measurement unless paired with the four conditions: bs, iodepth, numjobs, and rw |
| fio: BW (bandwidth) | Transfer volume per second | Roughly equal to IOPS × block size. This is the primary metric for a sequential measurement |
| fio: clat (completion latency) | Time until an I/O completes | Look at the 99th percentile and above, not just the average. High IOPS with a large tail latency still feels bad in practice |
| fio: slat / lat | Submission latency and overall latency | A large slat points to the issuing path on the kernel side rather than the device |
| fio: iodepth distribution | The queue depth actually sustained | If it never builds up to the specified iodepth, the load generator itself is the limiting factor |
| iostat: r/s, w/s | Measured read/write IOPS | This is the value of the real workload, not a benchmark. If it's far from the benchmark conditions, the benchmark's premise is off |
| iostat: rareq-sz, wareq-sz | Average I/O size (KB) | The real workload's I/O size — match fio's `--bs` to this value |
| iostat: r_await, w_await | Average wait time per request (ms) | If large despite IOPS headroom, it points to queue waiting or latency in a lower layer |
| iostat: aqu-sz | Average queue length | If it stays small while things are slow, storage is not the limiting factor; if large, the device cannot keep up |
| lsblk: ROTA | Whether it is rotating media (1 = HDD-class) | Confirms you haven't mixed up whether the target is HDD or SSD |
こういう状況で使います
- A product catalog's IOPS value differs significantly from what you measured yourself
- The same storage shows numbers that vary by multiples depending on who measures it
- A benchmark shows fast numbers, but database processing doesn't get as fast as expected
- Switching from SATA SSD to NVMe SSD made no perceptible difference
- Adding many NVMe drives didn't scale performance proportionally
- It's unclear whether to look at the sequential or random figure
考えられる原因（可能性の高い順）
01
An IOPS figure is not defined on its own
IOPS is just "I/O operations per second" — it only becomes meaningful once the size of a single I/O, the number of I/Os issued concurrently (queue depth), the read/write ratio, and whether the cache is bypassed are all fixed. Numbers missing any of these four cannot be compared.
02
Physical mechanics dominate random access on HDD
On rotating media, every random I/O involves moving the head (seek) and waiting for the sector to come around (rotational latency). Sequential access involves almost none of this, so the same device shows an order-of-magnitude gap between random and sequential.
03
The gap is not zero even on SSD/NVMe
With no moving parts, the random-vs-sequential gap shrinks dramatically compared to HDD, but it remains due to flash's page/block structure, write amplification, garbage collection, and mapping-table lookup cost. For writes in particular, the figure differs between the steady state (free space depleted) and the initial state.
04
SATA (AHCI) and NVMe have different queue structures
AHCI is fundamentally designed around a single command queue, limiting how many commands can be outstanding at once. NVMe is designed to have many deep queues per CPU core. This difference matters at high parallelism and shrinks at a queue depth of 1 with sequential access. If "switched to NVMe but it's not faster," the measurement conditions may be low-parallelism.
05
The benchmark is measuring the cache
Without `direct=1`, with a test size smaller than RAM, or with a run so short it only covers warm-up, what's being measured is the page cache or the controller's write-back cache.
06
The database's access pattern doesn't match the measurement conditions
Access to a database's data files is generally random-leaning, while writes to the transaction log are sequential and synchronous. Log writes are governed by write latency, not IOPS or throughput. A good sequential-read number does not guarantee either of these.
確認手順
- 1
Measure the real workload's I/O characteristics first
参照のみUse `iostat -x` to get `rareq-sz`/`wareq-sz` (average I/O size), `r/s`/`w/s`, and `aqu-sz` (queue length). Match the benchmark conditions to these.
- 2
Check the device configuration
参照のみUse `lsblk -o ...,ROTA,MODEL` and `nvme list` to determine what's actually being measured (HDD or SSD, local or network-attached).
- 3
Run fio with the measurement conditions explicitly stated
低Specify `--bs`, `--iodepth`, `--numjobs`, `--rw`, and `--direct=1`, and record the conditions as-is. A benchmark result without recorded conditions cannot be interpreted later.
- 4
Measure at several points with different queue depths
低Vary iodepth while recording both IOPS and latency. The point where IOPS plateaus but latency keeps climbing is the practical ceiling.
- 5
Run write tests until the steady state
中On SSD, a short measurement only shows the initial-state value. Set a long `--runtime` and exclude the ramp-up with `--ramp_time`.
- 6
Isolate layer by layer for a multi-device configuration
低Measure in order — a single device, the RAID/volume layer, the filesystem layer, and the application layer — to identify where the ceiling is.
対応方法
すぐに実施できる低リスクの対応
Align the measurement conditions of the two figures being compared
参照のみMatch I/O size, queue depth, parallelism, read/write ratio, the direct flag, and working-set size. If they cannot be matched, give up the comparison and re-measure under your own conditions.
Decide which metric to look at based on the goal
参照のみIf response time is the concern, look at latency (clat percentiles); if batch duration is the concern, look at bandwidth; if concurrency is the concern, look at IOPS. These are three different questions.
事前検討が必要な変更
Build a measurement profile matched to the real workload
低Build measurement conditions that reflect the average I/O size and queue length obtained from `iostat` into `--bs`/`--iodepth`, and keep measuring under those conditions going forward.
Raise parallelism to exploit NVMe's strengths
中NVMe's advantage shows up at high parallelism. If the application only issues sequential I/O, raising parallelism is more effective than swapping devices.
Separate log writes from data writes
中Co-locating sequential, synchronous log writes with random data access on the same device causes them to interfere with each other. Consider whether they can be separated.
再起動・サービス影響を伴う変更
Change the storage layer configuration
高Changing RAID level, stripe size, or recreating the filesystem involves migrating data. A prior backup and rollback procedure are mandatory.
専門家のレビューが必要な作業
Identify the bottleneck in a multi-device configuration at the design stage
専門家レビュー必須In a configuration with many NVMe devices, the limiting factor shifts from single-device performance to an upstream path. Candidates include the number and generation of PCIe lanes provided by the CPU/platform, the HBA/expander/backplane configuration, the link bandwidth of an external enclosure (DAS), the number of CPU cores available for interrupts and I/O processing, processing in the filesystem or software RAID layer, and ultimately the application's parallelism. Which one matters depends on the configuration, so measure layer by layer to identify it.
!注意事項
- This article gives no IOPS, bandwidth, or latency figure for any specific product. A product's performance figures depend on the model, firmware, configuration, and measurement conditions. Obtain any number you need either by measuring it yourself or from a published figure where the vendor states the measurement conditions.
- fio generates actual I/O load. Do not run it against production storage or a path that shares bandwidth with production.
- A measurement that includes writes (`randrw`, `randwrite`) overwrites the area specified in `--filename`. Never point it at an existing data file or device.
- A measurement without `--direct=1`, or with a working set smaller than RAM, is measuring the cache, not storage.
- SSD write performance measured over a short run does not reflect real-world values. It needs to run until the steady state, once free space has shrunk and garbage collection is active.
- The latency distribution can differ completely even with the same IOPS. Always check the tail latency at the 99th percentile and above, not just the average.
バージョン・環境による違い
これで解決しない場合に確認すること
Check whether the CPU is saturated
A high-IOPS measurement can consume all available CPU on interrupt handling and I/O issuing. Check CPU usage with `mpstat` alongside `iostat`.
Check the I/O scheduler setting
`none` is often appropriate for NVMe; leaving a rotating-media scheduler in place introduces unnecessary reordering.
Check filesystem alignment
A misaligned partition or stripe boundary splits a single logical I/O into multiple physical I/Os.
Check the application's concurrency
If things are slow without storage hitting a ceiling, the limiting factor is application-side parallelism or lock contention.
Obtain the measurement conditions for anything being compared
When comparing against a number from elsewhere, check whether that measurement's bs, iodepth, numjobs, rw, and direct flag are published. A figure without that is not comparable.
この文書の根拠と限界
一般的な技術説明
Based on general performance characteristics of storage I/O (seek and rotational latency on rotating media, write amplification on flash memory, and the queue-structure difference between AHCI and NVMe), and the public option specifications of fio and iostat. It includes no performance figures for any specific product or measurements from any specific environment. Obtain any figure you need through measurement in your own environment.
よくある質問
What's the difference between Random IOPS and Sequential IOPS?
It is whether the accessed positions are contiguous. On HDD, every random access involves a seek and rotational latency, so the gap from sequential spans orders of magnitude. On SSD/NVMe, with no moving parts, the gap shrinks dramatically, but it does not reach zero due to the internal structure of flash and the effect of garbage collection.
Can products be compared using IOPS figures alone?
No. IOPS only becomes meaningful once I/O size, queue depth, parallelism, read/write ratio, and whether direct I/O is used are all fixed. Numbers without these stated are not comparable. If you want a comparison, measure both yourself under the same conditions.
How much does Random Read IOPS differ between SATA SSD and NVMe SSD?
This article gives no figure. The size of the gap depends on the model, generation, and measurement conditions. The structural difference is that AHCI is centered on a single command queue, while NVMe can have many deep queues per core. This difference shows up at high parallelism and shrinks at a queue depth of 1 with sequential access. Confirm the actual gap with an fio measurement under identical conditions.
Does installing 24 NVMe drives make things 24 times faster?
No. Adding more drives shifts the limiting factor from a single device to an upstream path. Candidates include the number and generation of PCIe lanes on the CPU/platform, the HBA/expander/backplane configuration, the link bandwidth of an external enclosure, the number of CPU cores available for interrupts and I/O processing, processing in the filesystem or RAID layer, and the application's parallelism. Which one matters depends on the configuration, so measure layer by layer to identify it.
For a database, should Random or Sequential be the focus?
Both, but they play different roles. Access to data files is generally random-leaning, so random I/O performance matters there. Transaction log writes are sequential and synchronous, where write latency matters more than IOPS. Also note that co-locating the log and data on the same device causes them to interfere with each other.
Can this be run in production?
`lsblk`, `nvme list`, and `iostat` are read-only and can be run in production as well. Since fio generates actual load and a condition involving writes overwrites the specified area, do not run it in production — prepare a dedicated test area.
この文書がカバーする質問
- Difference in Random Read IOPS between SATA SSD and NVMe SSD
- Where the bottleneck is in a 24-drive NVMe SSD configuration
- Why a benchmark's IOPS value differs from the product catalog
- Does a database care more about random I/O or sequential
リスク表示の意味
- 参照のみデータと設定を変更しません。
- 低影響は限定的ですが、権限と負荷の確認が必要です。
- 中性能・ロック・コストに影響する可能性があります。
- 高障害・データ損失・復旧作業が発生する可能性があります。
- 専門家レビュー必須本番適用前に別途レビューが必須です。
GIIPの対応範囲
Everything up to this point is reproducible by anyone once the measurement conditions are aligned. What's hard in real operations is not measuring correctly — it's recording the conditions used and maintaining a state where the next measurement can be compared against it. At GIIP, an AI agent continuously collects I/O size, queue length, and wait time under identical conditions across several databases on AWS and Azure and roughly 30 web services, and a human specialist investigates the cause once a value deviates from the historical distribution. This mechanism is built to use a time series collected under consistent conditions as the basis for judgment, rather than a one-off benchmark figure.
執筆・技術検証
GIIP プロダクション運用チーム
大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。
What's the Difference Between EBS IOPS and Physical Disk IOPS
A document organizing why EBS IOPS cannot be compared directly to physical disk IOPS, based on where the ceiling applies (volume vs. instance) and how to measure it.
awsThe Difference Between One Large RDS Instance and Several Smaller Instances
A document organizing the technical differences between "one large instance" and "several smaller instances" for RDS sizing, and the CloudWatch metrics you should measure before deciding.
sql-serverHow to Check Transaction Log Usage on RDS for SQL Server
A read-only procedure that checks log usage with DBCC SQLPERF(LOGSPACE) and sys.dm_db_log_space_usage, and isolates the reason it is not being released using log_reuse_wait_desc.
monitoringWhat to Configure When Monitoring Servers and Databases 24/7
A checklist, organized by layer, of what to monitor, how to think about thresholds, the escalation structure, and why synthetic monitoring is necessary when designing 24/7 monitoring.
関連サービス
Get a consultation on storage performance measurement conditions
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
Get a consultation on storage performance measurement conditions