第9回目は、2013年9月のKVMゲストOSベンチマーク2本からです。
なにげにやってみるとOSによってかなりの違いがあって、その辺に好奇心がでてきたんだろうけれども、むずかしいお話だったよね。
今でもこれだけの差が出ることについては分かってないんだなこれが。面白いネタなんだけれども詰めが甘いのよ。
そんな当時分からずじまいだったことをAIニキの力を借りて解決していくシリーズの8回目です。
ファイルシステムのせいだと思ってEXT3に変えてみたら全然変わらなかった。多分ファイルシステムくらいしか思いつかなかったんかな。仮説を立てて検証して外れた。というのは非常に正しいアプローチだったんだけど。
まずUnixBenchとは何を測っているのか
UnixBenchというのは「OSとしての総合的な処理能力」を測るベンチマークで、CPUだけを測るものではない。
項目を大きく分けると3種類あって。
CPU系（計算の速さ）
- Dhrystone：整数の計算
- Whetstone：小数点の計算
OS系（OSの処理の速さ）
- System Call Overhead：プログラムがOSに頼み事をする速さ
- Pipe Throughput：プロセス間でデータを受け渡す速さ
- Process Creation：新しいプロセスを生み出す速さ
I/O系（ファイルの読み書きの速さ）
- File Copy：ファイルをコピーする速さ
ここが重要で、UnixBenchのスコアはCPUが同じでも、カーネルのバージョンや最適化の仕方などによって大きく変わる。
つまり「同じハードウェアでもOSが違えばスコアは全然違う」という話で、これがこの実験の謎の核心だった。最近は当時よりも仮想化環境はよく使うし、用途でアーキテクチャ変えたりして、それで速度もめちゃ変わったりするよね。
こういうアプローチができると良いよね。
パート1 謎の発見
同じ環境でCentOS、Ubuntu、Debian、FreeBSDのゲストOSを立てて、UnixBenchを走らせてみたら、こんな結果が出た。
スコア
CentOS : 1060.9
Ubuntu : 1088.1
Debian : 1663.5 ← なんでこんなに高い？
FreeBSD : 436.3 ← なんでこんなに低い？
CentOSとUbuntuはほぼ同じくらいなのに、Debianが突出して高くて、FreeBSDが突出して低い。環境は全部同じはずなのに。
ファイルシステムの違いじゃないかと目をつけた。
CentOS : EXT4
Ubuntu : EXT4
Debian : EXT3 ← これが原因？
FreeBSD : UFS
パート2 仮説を検証したら外れた
というわけで、CentOSをEXT4からEXT3に変えて同じベンチマークをやってみた。
CentOS EXT4 : 1060.9
CentOS EXT3 : 1044.7 ← むしろちょっと下がった
ほぼ変わらなかった。ファイルシステムは関係なかった。当時はなにもわからず。もう叫ぶしかなくなっちゃったよと。
なぜDebianだけ突出して高かったのか
ファイルシステムじゃないとしたら何か。数字を見直してみると答えのヒントがある。
System Call Overhead（システムコールの速さ）
CentOS : 1449.2
Ubuntu : 703.5
Debian : 2951.9 ← 断トツで高い
FreeBSD : 460.5
Debianだけシステムコールが突出して速い。CPUは全部同じはずなのに。
そもそもシステムコールというのは、プログラムがOSのカーネルに「ファイルを開いてくれ」「メモリをくれ」と頼む仕組み。この「頼む」という行為のたびに、プログラムが動いているユーザー空間からOSが動いているカーネル空間に切り替わる必要があって、このスイッチングのコストがどれだけ小さいかがSystem Call Overheadで、Debianはここが突出して速かった。
なぜか。
① カーネルの最適化の違い
CentOSは安定性を優先するため、最新の最適化が入っていないことがある。
Debianは当時、システムコール周りの最適化を積極的に取り込んでいたと考えられる。
② VDSOの違い
vDSOとは何か？
通常、システムコールは「ユーザーモード」から「カーネルモード」への切り替え（コンテキストスイッチ）を伴い、これがCPUにとって大きなオーバーヘッドになる。 vDSOは、カーネルの一部を「共有ライブラリ」として各プロセスにマッピングすることで、カーネルモードに切り替えずにユーザー空間のまま特定の処理を完結させる。一部のシステムコールをカーネル空間に入らずにユーザー空間で処理してしまう仕組みだ。
Debianはこのあたりの実装が当時進んでいた可能性が高い。というしらんけど結果からしてそうじゃないのかなぁっていう。しらんけど。
UbuntuがFile Copyは速いがSystem Callでは遅い
Ubuntuでは、File Copyでは速いのにSystem Call Overheadでは遅い。
File Copy 1024
Ubuntu : 1771.7 ← 速い
CentOS : 1436.6
Debian : 2384.6
System Call Overhead
Ubuntu : 703.5 ← 遅い
CentOS : 1449.2
Debian : 2951.9
Ubuntuは「メモリをキャッシュとして最大限利用してI/Oを最適化」してい流。
「システムコールというOSへの要求の橋渡し」にはコストがかかるため、小さな操作が大量にあると遅く感じられる。かもしれん。
ファイルを大量に読み書きするような用途ならUbuntuが有利で、システムコールを大量に発行するような用途ならDebianが有利、ということになる。ベンチマークの数字は「何に使うか」とセットで見ないと意味がない、ということだ。
FreeBSDがなぜ壊滅的に低かったのか
FreeBSDのFile Copyのスコアを見ると、
File Copy 1024
Debian : 2384.6
CentOS : 1436.6
Ubuntu : 1771.7
FreeBSD : 155.8 ← 15分の1以下
これはKVMの仮想化ドライバの問題だった可能性が高い。
Proxmox VEの公式ドキュメント（Windows VirtIO Drivers）によると、virtioというのはKVM環境でゲストOSが直接（準仮想化された）デバイスにアクセスするための仕組みで、エミュレーションよりも高速なI/Oを実現するものだ。
Linuxのゲストはvirtioドライバが標準で使ってたんじゃあないだろうかってところだ。Linuxはvirtioドライバがカーネルに組み込まれているから何もしなくても使える、でもFreeBSDは当時はvirtioサポートが未成熟で、素のエミュレーションで動いていた可能性が高かったかもしれない。
お題はめちゃ良かったなあ。
結局のところ、同じハードウェアの上に同じ仮想化基盤を敷いて、同じベンチマークを走らせても、OSが違えばスコアは全然違う。なぜ違うのかというところまでは手が届かなかった。カーネルの最適化の方針が違う、システムコールの処理戦略が違う、仮想化ドライバの成熟度が違う、全部が少しずつ違っていて、その「少しずつ」が積み重なってスコアという一つの数字に出てくる。
ベンチマークというのは答えじゃなくて問いなのか。
当時はその「なぜ」の先に進む道具も知識も足りなくて、叫んで終わった。