サーバーと仮想マシン

カーネルのSamepage Merging：仮想化パフォーマンスを向上させるKSM

KSM 仮想化 LinuxカーネルがVM間で同一のメモリページを統合し、コピーオンライト（Copy-on-Write）によって効率的に共有することで、物理RAMの要件を削減します。これにより、VM密度を高め、RAMのボトルネックを緩和し、 パフォーマンス バランスが取れている

中心点

以下の要点は、KSMを素早く理解し、目的意識を持って活用する上で役立ちます：

重複排除 同一のメモリページを使用することで、RAMの使用量を大幅に削減できます。.
コピー・オン・ライト ページをまとめて読み取り可能な状態に保ち、変更があった場合にのみそれらを分離します。.
微調整 ksmdパラメータによって、CPU負荷とコスト削減のバランスが取られています。.
NUMAロケーション マルチソケットホストにおける不要なレイテンシを防止します。.
セキュリティ マルチテナント環境では、選択的な共有が必要となります。.

KSMとは？　基礎知識と流れ

と一緒に カーネルの同一ページマージ カーネルスレッド ksmd は、「mergeable」とマークされた匿名のプライベートページを定期的にスキャンし、ビット単位で同一の内容を統合します。多くの VM が、同一のライブラリ、プログラムコード、または OS コンポーネントをメモリに保持していることが多いため、私はこの仕組みの恩恵を受けています。KSM は、統合されたページを コピー・オン・ライト, 。これにより、誰かが書き込みを行うまでは、すべてのゲストが同じ物理ページを読み取ることになります。書き込みアクセスが行われた時点で初めて、カーネルはそのプロセス用に独自のページを生成し、元のページは引き続き共有されたままとなります。重要：KSMはファイルシステムやページキャッシュのページを重複排除せず、マージのためにメモリを明示的に解放する必要があります。.

仮想化環境での活用

類似したVMが多数存在するホストでは、 KSM 冗長なページが頻繁に発生するため、最大の効果が得られます。KVMやクラウド環境では、マージ処理によりゲスト1台あたりの実質的なRAM負荷が大幅に軽減され、その結果、サーバーあたりのVM密度が向上します。実運用における事例報告によると、適切なチューニングを行えば、応答時間に目立った低下を招くことなく、最大で300 %ものゲストシステムを追加できるとのことです。KSMをメモリのオーバーコミットメント, これによりホストの稼働率を高め、既存のメモリをより効率的に活用できます。同一のページを共有することで、スワップの急増リスクを低減し、スムーズな 出力特性曲線 多くの段階を経て。.

LinuxおよびKVMでの設定

起動させる KSM カーネルの CONFIG_KSM を通じて、/sys/kernel/mm/ksm/ 配下の sysfs 経由で動作を制御しています。そこでスキャンを開始（run）し、強度（pages_to_scan、sleep_millisecs）を設定して、ページ獲得量を (pages_sharing)を観察します。エンタープライズ向けディストリビューションでは、ksmやksmtunedといったサービスを利用し、空きRAMの閾値に基づいて自動的にスケールアップまたはスケールダウンを行います。きめ細かな制御を行うために、madvise(MADV_MERGEABLE) や prctl(PR_SET_MEMORY_MERGE) を使って、メモリ領域を意図的に「統合可能」としてマークします。動的な環境では、KSMをメモリー・バルーンを最適化する。 RAMの割り当て さらに柔軟性を保つ。.

性能とチューニング：適切なバランス

特に、RAMが真のボトルネックとなり、CPUコアが遊休状態になってしまうような場面で性能が向上します。その場合、 KSM 並列で動作させるVMが増えたため、全体的なパフォーマンスが向上しています。ただし、ksmdスレッドはCPU時間を消費するため、スキャンパラメータの設定が過度に積極的すぎると、そのメリットが薄れてしまう可能性があります。私はまず控えめな設定から始め、pages_sharingやpages_scannedを測定し、負荷時のレイテンシを観察してから、スキャンレートを上げていきます。十分な空きRAMがある場合は、ksmdの活動を控えめに保ち、ホストが不足し始めてから初めて設定を強化します。そうすることで、 記憶容量の増加 およびCPUのオーバーヘッド。.

安全性と隔離について客観的に考察する

複数のゲストが物理的なページを共有しているため、潜在的な 側方チャネル, 、これらはタイミングやアクセスパターンから情報を推測される可能性があります。機密性の高いマルチテナント環境では、特定のインスタンスやホストに対してページ共有を個別に無効にしています。一方、同種のゲストが多数存在する、それほど機密性が高くないワークロードの場合、KSMはコスト削減と密度向上を図るための信頼できる手法です。私はクラスタごとにその決定内容を文書化し、特に重要なVMについては例外リストを用意しています。このようにして、私は 透明性 そして、効率の向上を損なうことなく、攻撃対象領域を縮小する。.

NUMA、Huge Pages、および相互作用

NUMAシステムでは、以下の点に注意しています 保管場所 また、アクセスが遅い経路を経由しないように、KSMのマージは理想的には1つのノード内でのみ行うようにしています。これによりレイテンシが低減され、ソケットあたりの帯域幅を高く維持できます。 Huge Pagesと組み合わせることでTLBミスを削減できますが、ページサイズが大きいとビット単位で同一のコンテンツが存在する確率が変化することに留意する必要があります。ワークロードによってはHuge Pagesの恩恵が大きいものもあれば、重複排除の恩恵が大きいものもあります。私はベンチマークを用いてこれを検証しています。目標は、ローカルアクセスを最大化し、 遠隔記憶装置 を避けなければならない。

モニタリングと指標の理解

私は、以下の効果を評価しています。 KSM 少数ながら意味のあるメトリクス、すなわち pages_sharing、pages_shared、pages_scanned、pages_unshared、full_scans に基づいて評価します。pages_sharing が安定して上昇し、CPU 負荷が適度な範囲に収まっていれば、私のセットアップは望ましい方向に進んでいると言えます。数値が横ばいのままの場合は、ゲストがメモリを「マージ可能」としてマークしているかどうかを確認します。さらに、副作用を早期に検知するために、ホスト・スワップ、VMのレイテンシ、IO待機時間も監視しています。時系列データを含むダッシュボードで傾向を把握することで、調整データに基づいて判断する。.

実践事例とコスト削減の可能性

数十台の類似したLinux VMで構成されるテストクラスターにおいて、私はおかげで KSM RAM使用量をパーセンテージポイントで2桁削減できたケースもあり、その結果、密度が著しく向上しました。同一のクラスやライブラリを多く含むJavaワークロードでは、特に一貫したパフォーマンス向上が見られました。ゲストが均質であればあるほど、メモリ使用量は大幅に削減されます。異種スタックの場合、その効果は小さくなりますが、それでも有用な結果が得られます。適切に設定されたオーバーコミットと組み合わせることで、インスタンスあたりのコストを低く抑え、同じハードウェア上でより多くのサービスを運用できます。これにより、明確な 経済効果 予測可能な品質で。.

KSM対代替案：違いと相互関係

私は……に賭ける ポートフォリオ 目的によって異なる効果を発揮する、補完的なメモリ技術です。KSMはRAM内の冗長性を排除し、バルーニングはゲストに対して動的にメモリを回収し、Huge PagesはCPUの効率を高めます。いずれの技術も互いに代替するものではなく、私はワークロードのプロファイルや密度目標に応じて、これらを意図的に組み合わせています。初心者の方には、以下の概要が選択を迅速に行うのに役立ちます。次のステップとして、以下を確認することをお勧めします。 KVM と Xen 比較して、その プラットフォームの選択 適切に分類する。.

テクノロジー	タスク	メリット	デメリット	こんな人に向いている
KSM	同一のRAMページの重複排除	高い RAMの節約類似のVMの場合	スキャンによる追加のCPU負荷	同様のゲストが多数、KVMホスト
メモリー・バルーン	ガス貯蔵施設の動的回収	より良い利用ワークロードが変動する場合	ゲスト1人につきバルーン操縦者1名が必要	さまざまな稼働率のパターン
巨大なページ	ページサイズを大きくしてTLBミスを減らす	より高い CPUの効率メモリを大量に消費するアプリの場合	重複排除の可能性が低い	データベース、JVM、インメモリエンジン
NUMAピンニング	VMのローカルストレージノードへのバインド	定数レイテンシーおよび帯域幅	スケジューリングの柔軟性が低下する	マルチソケット・ホスト、レイテンシが重要なワークロード

実用的な有効化とホスト・プレイブック

ホストレベルでは、実用的なアプローチをとっています。ksm/ksmtuned を起動し、運用で実績のある基本設定値を指定します。例：

# サービスの有効化（ディストリビューションに依存）
systemctl enable --now ksm ksmtuned

# 手動チューニング（即座に有効、再起動まで有効）
echo 1 > /sys/kernel/mm/ksm/run
echo 1000 > /sys/kernel/mm/ksm/pages_to_scan
echo 50 > /sys/kernel/mm/ksm/sleep_millisecs

libvirt では、VM ごとに共有設定を管理しています。デフォルトでは、QEMU はゲスト RAM を「マージ可能」として設定しています。特に機密性の高い VM については、共有を明示的に無効にしています：

そこで、私は明確な方針を貫いています。すなわち、ワークロードが均一なホストでは広く有効化し、例外については的を絞ったオプトアウトを行うというものです。.

KSMパラメータの微調整の詳細

run: 0 = オフ、1 = 有効、2 = オフ、かつすでにマージされたページをアンマージする。私は「2」を、特定のテストを行う場合や、メンテナンス期間前にシェアリングを確実に元に戻したい場合にのみ使用しています。.
スキャンするページ数: 1サイクルあたりにチェックされるページ数。この値を高くすると、同一ページの検出が速くなりますが、CPUへの負荷が高まります。.
sleep_millisecs: サイクル間の休止。休止時間を長くするとオーバーヘッドは低減されますが、節約効果が頭打ちになるまでに時間がかかります。.
merge_across_nodes: NUMAホストの場合、NUMAノード内でのみマージが行われるように、これを0に設定しています。これにより、局所性が保たれます。.
use_zero_pages: これを有効にすると、プロセスはゼロページをカーネルのゼロページと効率的に共有します。これにより、COWのオーバーヘッドなしに「確実な」メモリ節約が実現されます。.

ksmtuned を使用すると、RAM のしきい値に基づいて動的に調整を行うことができます。空きメモリが不足し始めると、ksmtuned はスキャン速度を向上させ（Npagen-Boost）、負荷が低下すると再び速度を落とします。これにより、手動での操作を必要としない、適応性のある「呼吸する」ような設定が実現されます。.

THP、Huge Pages、およびバルーニングとの相互作用（詳細）

透明な巨大ページ（THP） そして 巨大なページ CPUの効率を最適化すると同時に、KSMによってRAM内の冗長性を削減します。その際、以下の点を考慮しています：

KSMは通常の4KBページを扱います。THPページ（通常2MB）は重複排除できません。THPの適用度が高ければ高いほど、KSMが処理できるデータ量は少なくなります。.
レイテンシが重要なワークロードやCPUに依存するワークロードでは、THP/Huge Pagesを優先します。RAMが不足しているホストで、構成が均一なVMが稼働している場合は、KSMを優先します。.
BallooningはKSMを補完します。Balloonドライバは、空きガスメモリをホストに返します。一方、KSMは同一のページを統合することで、並行してメモリ需要を削減します。これらを組み合わせることで、ピーク負荷を平準化し、時期尚早なスワッピングを防ぎます。.

私は実証的に判断します。THP/Huge Pagesの有無やKSMの有効・無効といった条件でベンチマークを実行することで、どの組み合わせが最も優れた総コストパフォーマンスをもたらすかが分かります。.

セキュリティモデルと最新のCPU機能

次のような環境では 厳格な顧客分離 私はVMやホストごとにSharingを徹底して無効にしています。これにより、共有ページによる横方向の情報伝達経路が最小限に抑えられ、コンプライアンス監査が簡素化されます。最新の ストレージの暗号化 ホスト／ゲストレベル（例：VMごとのキー）でのこの仕組みは、実際には、同一のコンテンツが物理RAM上でもはやビット単位で一致しなくなるため、KSMがゲスト間で適切にマージを行うことを妨げてしまいます。このようなクラスターでは、CPUリソースを無駄に消費しないよう、積極的なスキャンは控え、ksmdをどちらかといえば受動的な状態に保っています。.

感度は低いが均質なスタックについては、KSMをデフォルトのままにしています。クラスターごとにポリシーを文書化しています。「デフォルトで有効、nosharepagesによる例外」または「デフォルトで無効、定義されたプールのみを共有」――透明性があり、再現可能な形で実装されていれば、どちらの構成も有効です。.

ワークロードへの適合性とアンチパターン

KSMは、均一でライブラリを多用するワークロード（例：同一のアプリケーションサーバーが多数ある場合、JVMベースのサービス、エージェントなど）においてその真価を発揮します。一方、以下のケースではそのメリットを十分に活かせません：

変動が激しく、短期間で変化する資産配分 （例：小さく、頻繁に変更されるバッファが多数ある場合など）、COWが発生する可能性が高いからです。.
圧縮されたデータ、暗号化されたデータ、または擬似ランダムなデータ – 同一のページはほとんど見られない。.
大規模なインメモリDB データが急速に変化する場合、積極的なページリサイクルが行われます。このような場合、Huge Pages/THPの利点がしばしば上回ります。.

コンテナファームにおいても、プロセスがストレージを「マージ可能」としてマークしている限り、KSMは機能します。しかし実際には、QEMUがすでに必要なmadviseフラグを設定しているため、私はKSMを主にVMに焦点を当てています。.

トラブルシューティングと典型的な障害

pages_sharingの伸びが鈍化している: QEMU/VMが実際にマージ可能なメモリを割り当てているか（libvirt-XMLにnosharepagesディレクティブがないか）、またksmdが動作しているかを確認します。メモリがフラットなままの場合は、ワークロードの異種性が過度である可能性があります。.
CPU負荷が高すぎる: `sleep_millisecs` を増やしたり、`pages_to_scan` を減らしたりします。さらに、検索範囲を狭めるために、NUMA 間マージを無効にすることもできます。.
予期せぬレイテンシーの急上昇: COWイベントが負荷のピークと相関しているかどうかを確認します。そのような場合は、スキャンレートを緩めるか、影響を受けているVMを一時的に共有から除外します。.
オーバーコミットがスワップへとエスカレートする: KSMはキャパシティプランニングの代わりにはなりません。私は常に空きRAMの余裕を確保しており、ksmdはあくまでバッファとして調整しており、緊急時の応急措置としては使用していません。.

計画、サイジング、および自動化

予測可能な結果を得るために、ホストごとに目標値を定義します：

ヘッドルーム: 空きRAMの一定割合のバッファ。これを下回ると、ksmtunedの動作がより積極的になります。これにより、重複排除処理を実際に必要とされる局面に限定して実行できるようにしています。.
公平性: ワークロードにばらつきがある場合は、プール（例：プロジェクト別／環境別）を分離し、同種のVMが互いに恩恵を受けられるようにするとともに、異種のVMによる「効果の希薄化」を防ぐようにしています。.
限界値: 最大スキャンレートに上限を設定し、そのコスト削減効果がCPUの使用量を正当化するものかどうかを定期的に確認しています。.

自動化において、私はKSMを、再現性があり、バージョン管理されたプレイブック（例：SystemdドロップインやCloud Initスニペット）として捉えています。これにより、新しいホストが同一のパラメータセットで稼働することを保証し、差異があればすぐに気づくことができます。.

管理者向けまとめ

私はこうしている。 KSM, ホストが多くの類似したVMをホストしており、RAMがリソースのボトルネックとなっている場合です。その際は、重複排除が最大の効果を発揮し、一方でksmtunedやsysfsパラメータを用いてCPUコストをきめ細かく制御します。 NUMA環境では、マージ処理をローカルに限定し、KSMをバルーニングやHuge Pagesと組み合わせて使用し、pages_sharingやレイテンシ指標を通じてその効果を測定します。影響を受けやすいゲストについては、共有機能を意図的に無効にし、例外については透明性を持って記録します。このようにして、私は密度, 、確実な応答時間を確保し、インスタンスあたりのユーロコストを持続的に削減します。.