DISK 管理の性能差を検証してみよう～直接xfs、LVM、nfsの性能差～

こんにちは。サイオステクノロジーの橋本です。

今回は DISK (ボリューム) 管理方法の違いによる性能差を見ていきたいと思います。

よくこういう意見耳にしませんか?
　LVM はオーバヘッドがあるから遅い
　NFS は非常に遅いのでバックアップ用に適している
　物理ボリュームに直接ファイルシステムを作成する方法が一番無難 (そして DISK 拡張できず運用になやむ)
実際にどれくらいの性能差があるのか以下の 4 パターンで検証してみます。

1 検証パターン
2 前提
3 検証方法
4 検証結果 : latency average
5 検証結果 : tps
6 所感
7 最後に

検証パターン

1: 物理ボリュームに直接ファイルシステム (以下、「直 xfs」と呼称)
　50 GB の DISK 1 本をサーバにアタッチ
　LVM など用いずに DISK 上に直接ファイルシステム (xfs) を作成

2: 物理ボリューム 1 本で 1 つのボリュームグループ作成 (以下、「LVM ×1」と呼称)
　50 GB の DISK 1 本をサーバにアタッチ
　LVM を用いて対象の DISK 論理的に管理しファイルシステム (xfs) を作成

3: 物理ボリューム 25 本で 1 つのボリュームグループ作成 (以下、「LVM ×25」と呼称)
　2 GB の DISK を 25 本用意し、すべてをサーバにアタッチ
　LVM を用いて 25 本の DISK を 1 つのボリュームグループとして束ね、ファイルシステム (xfs) を作成

4: NFS
　文字通り NFS (Network File System)
　DISK 管理方法と異なるレイヤーですが、NFS 上に PostgreSQL のデータを格納し検証してみます。

なお、NFS サーバは同一 AZ 内に別サーバとして用意しました。

※raw デバイスは RHEL 9 から利用できなくなったので
　今回は検証しません(できません)

前提

主要なパッケージやOSのバージョン

OS バージョン	Red Hat Enterprise Linux release 9.4
Kernel	kernel-5.14.0-427.13.1.el9_4.x86_64
PostgreSQL	postgresql16-16.2-1PGDG.rhel9.x86_64
LVM	lvm2-2.03.23-2.el9.x86_64
nfs	nfs-utils-2.5.4-25.el9.x86_64

サーバのリソース

CPU	2コア
メモリ	8GB

DISK

OS 領域	15GB
検証用 (DB) 領域	50GB

OS 領域はいずれの検証パターンでも LVM を用いず DISK 上に直接ファイルシステム (XFS) を作成したものを利用

DISK サイズはすべての検証パターンで 50 GB になるように調整しサーバにマウントしました。
マウントした 50 GB を PostgreSQL のデータ領域 ($PGDATA) として利用します。

当然いずれの検証パターンにおいても DISK そのものの性能差はありません。

検証方法

検証はすべて pgbench を用います。
以下のコマンドを用いて検証用のデータを作成しました。

pgbench -i -s 2500 TESTDB

以下のように負荷を掛けることで DISK 性能を計測します。

# pgbench -c 200 -t 100 TESTDB
pgbench (16.2)
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 2500
query mode: simple
number of clients: 200
number of threads: 1
maximum number of tries: 1
number of transactions per client: 100
number of transactions actually processed: 20000/20000
number of failed transactions: 0 (0.000%)
latency average = 182.821 ms
initial connection time = 754.209 ms
tps = 1093.966050 (without initial connection time)
#

噛み砕いていうと同時に 200 クライアントが DB に接続を行い、
それぞれのクライアントが 100 トランザクションを実行します。

今回、以下の 2 点の結果を見ます。
・latency average
　1トランザクションの実行時間 (単位は ms)
　数値が短い程高速に完了していることを示します。

・tps = xxxxxx (without initial connection time)
　1 秒あたりの実行トランザクション数 (接続確立に要した時間を考慮せず)
　数値が大きい程大量のトランザクションを処理していることを示します。

なお、検証はブレを考慮してそれぞれのパターンで 10 回行います (計40回検証)。

検証結果 : latency average

検証 10回のサマリ

	平均値	最小値	最大値
直 xfs	185.8769 ms	181.374 ms	189.893 ms
LVM ×1	185.5508 ms	180.168 ms	198.081 ms
LVM ×25	188.4649 ms	182.428 ms	197.622 ms
nfs	243.9293 ms	227.067 ms	254.882 ms

個別の結果 (単位はすべて ms)

	1回目	2回目	3回目	4回目	5回目	6回目	7回目	8回目	9回目	10回目
直 xfs	182.821	185.401	181.519	188.62	185.515	189.893	181.374	189.672	184.623	189.331
LVM ×1	180.691	180.168	182.824	192.308	181.503	198.081	183.759	191.254	182.587	182.333
LVM ×25	182.428	186.594	185.742	192.513	187.926	197.622	185.209	187.631	186.238	192.746
nfs	227.067	229.767	248.523	254.183	244.819	247.029	254.882	236.622	254.582	241.819

検証結果 : tps

検証 10回のサマリ

	平均値	最小値	最大値
直 xfs	1076.294	1053.222	1102.692
LVM ×1	1078.886	1009.69	1110.075
LVM ×25	1061.742	1012.033	1096.325
nfs	821.1957	784.6754	880.7962

個別の結果

	1回目	2回目	3回目	4回目	5回目	6回目	7回目	8回目	9回目	10回目
直 xfs	1093.966	1078.742	1101.81	1060.335	1078.079	1053.222	1102.692	1054.451	1083.29	1056.351
LVM ×1	1106.864	1110.075	1093.947	1039.999	1101.913	1009.69	1088.381	1045.73	1095.371	1096.891
LVM ×25	1096.325	1071.844	1076.765	1038.889	1064.246	1012.033	1079.861	1065.923	1073.894	1037.636
nfs	880.7962	870.4461	804.7554	786.8345	816.9299	809.6224	784.6754	845.2306	785.601	827.0654

所感

所感としては「直 xfs」と「LVM ×1」の差はほぼ無いと言えます。
平均値として 0.3 ms の差なので誤差の範疇だと推測します。
※ 0.3 ms の差が致命的になるシステムも金融、証券系などで存在するため
　そういう場合はより厳密な検証が必要です

しかしながら、LVM で束ねている物理 DISK の数が多くなると、
3 ms と有意な差が現れ始めました。
おそらくですが物理 DISK が多くなるとこの差はより広がると推測されます。
「気にする程度か？」という気もしますが、
ここら辺になるとチリも積もればで影響が出るシステムもあるかもしれません。

nfs は DB として利用できないくらい遅い、、、と検証前思っていましたが
大分健闘した数値となりました。
※同一 AZ 内だったのでこれくらいの数値に収まったと推測します。

ちなみに伝わる人には伝わると思いますが、
格闘ゲームでよく言われる「フレーム」ですが
1 フレームは約 16ms です。
また、人間の反応速度の限界は(諸説ありますが) 200 ms 前後といわれます。
一般的なモニターの応答速度で5 ms前後です。

個人的な主観で言いますと、
LVM を用いた時に生じた数 ms の差は人間が知覚できない範囲の話であり、
シビアなシステムでない限り LVM の利便性を捨てる理由にはならないと考えます。