コンテンツにスキップ 
ホスティングサーバー上のWebサービスやデータベースサービスの応答速度を向上させ、I/O負荷を軽減するために、vm.swappinessをどのように設定すべきかをご紹介します。明確な手順、適切な初期値、そしてモニタリングを活用することで、既存のRAMを最大限に活用し、 遅延時間 そして、不要なスワッピングを防ぎます。.
中心点
これらのポイントを押さえておけば、すぐに実践できるチューニングの要点を素早く把握できます。.
- Swappinessの挙動: カーネルがRAMをスワップ領域に移動させるタイミングを制御します。.
- ワークロードとの関連性: データベースやWebなどのアプリケーションの種類に合わせて値を調整してください。.
- 一時的にテストする: まずは実稼働環境で検証し、その後、恒久的に確定する。.
- スワップレイアウト: 規模、範囲、優先順位を考慮に入れる。.
- モニタリング: I/O、RAM、および応答時間を監視・調整する。.
vm.swappinessとは何か、そしてその仕組み
カーネルパラメータ vm.swappiness LinuxがRAMからスワップ領域へメモリページをどの程度積極的に移動させるかを決定します。現在の値は、疑似ファイルシステムの /proc/sys/vm/swappiness で確認でき、実行時または永続的に変更することができます。 値が高いとスワップが早くなり、低いとRAM内のデータをより長く保持します。目標は、RAMの使用率、ページキャッシュ、および制御されたスワップ動作の適切なバランスを取ることです。私は常に次のことを念頭に置いています：RAMはどのSSDよりもはるかに高速であるため、私は ワーキングメモリ スワップより明らかに。.
ホスティングサーバーにおいてSwappinessが重要な理由
Webサーバーおよびアプリケーションサーバーでは、次の設定が重要となります。 スワップネス 応答時間とスループットについて。過度なスワッピングは追加のI/O負荷を生み出し、特にデータベースを多用するワークロードにおいて、リクエストの処理を遅らせます。一方、値が低すぎると、後でOOMイベントが発生し、プロセスが突然終了するリスクがあります。 そのため、私はRAMやスワップに加え、典型的な負荷のピーク、キャッシュ、およびクエリのパターンも評価しています。レイテンシを低減することで、動作のカクつきを防ぎ、トランザクションの処理を目に見えてスムーズに保つことができます。 液体.
ワークロードに応じた推奨事項
すべてのシナリオに単一の値が当てはまることはめったにないため、まずは実運用で実績のある範囲から始め、その後、測定データに基づいて調整しています。 データベースでは非常に低い設定が有効ですが、純粋なWebサーバーの場合は、多少高い値でも問題のないことがよくあります。テスト環境や開発環境では、利便性がより重要となるため、標準値に近い設定で運用できます。以下のスキームを、実用的な導入の指針として活用しています。 ホスティング-ワークロード。その後、I/O、スワップ使用率、応答時間を監視し、必要に応じて微調整を行います。.
| ワークロード | 推奨されるSwappiness | ゴール |
|---|---|---|
| データベース (MySQL、PostgreSQL) | 0–10 | RAMにバッファを保持し、レイテンシを低く抑える |
| リアルタイム／低遅延 | 0–10 | スワップによるI/Oのピークを回避する |
| ウェブサーバー キャッシュ付き | 10～20（一部は10～30） | 冷たいページをスワップアウトし、アクティブなリクエストをRAMに保持 |
| 開発・テスト | 30～60 | レイテンシーよりも快適性と安定性を優先 |
現在の値を確認する
値を変更する前に、ステータスを読み取り、その内容を記録します。 ベースライン. これには `cat /proc/sys/vm/swappiness` または `sysctl vm.swappiness` を使用しています。どちらの方法でも 60 といった数値が得られます。並行して、`free -h` を使って RAM とスワップ領域の使用状況を確認します。 swapon –show を実行することで、アクティブなスワップデバイスのサイズ、優先度、メディアを確認できます。これらの初期データは、後でその効果を 割り当てる ができるようになる。
すぐに恒久的な変更を行うのではなく、まずは一時的にテストしてみる
まずは試しにSwappinessを導入し、実際の環境での反応を 負荷 確認できます。sysctl vm.swappiness=10 コマンドは即座に効果を発揮しますが、再起動までしか持続しません。テスト中は top や htop を監視し、vmstat や iostat を確認しながら、各サービスの応答時間を測定します。 スワップ率が低下し、レイテンシが安定している場合は、妥当な範囲で段階的に調整を進めます。メトリクスが納得のいく結果となった時点で初めて、その値を記述します。 パーマネント 固定。.
永続的に設定する
テスト結果が適切であれば、それをsysctlの設定ファイルに記述し、設定を再読み込みします。/etc/sysctl.conf に vm.swappiness=10 という行を追加し、sysctl -p を実行して有効にします。 より整理された方法として、/etc/sysctl.d/ 配下に 99-swappiness.conf といった独自のファイルを作成し、sysctl –system で読み込むようにしています。これにより、バージョン管理が容易になり、自動化にも組み込みやすくなります。関連するパラメータに関するより詳細な概要については、以下の記事をご覧ください。 sysctl チューニング, 、変更点の整理を手伝ってくれるし、 クラリティ を持ってくる。
スワップ領域のサイズ、メモリレイアウト、およびデータストレージ
Swappinessは決して単独で作用するものではないため、私はその大きさや位置を評価している。 スワップ 常に考慮すべき点です。スワップ領域が小さすぎるとすぐに満杯になり、大きすぎると負荷がかかった際にI/O処理時間が長引きます。SSDやNVMeではHDDよりもスワップ処理が高速ですが、RAMには依然として数桁の差があります。優先順位を設定した複数のスワップデバイスを用意することで、最も高速なメディアを優先して使用できるようになります。 メリットとデメリットについてさらに詳しく知りたい方は、こちらの概要をご覧ください。 ホスティングにおけるスワップ ～のための有益な示唆 練習.
実務のワークフロー：ステップバイステップ
まずは現状把握から始めます。現在のSwappiness値、RAMおよびスワップの使用率、CPUおよびI/Oの状態を記録し、それを 参考 バックアップを取る。その後、ワークロードを分類する：主にデータベース、キャッシュ付きWeb、混合環境、またはコンテナ化された環境。続いて目標値を定義する：データベースは0～10、Webは通常10～20、混合負荷については慎重に調整する。 この値を一時的に設定し、複数の負荷フェーズを観察してメトリクスを比較します。結果が繰り返し一致すれば、その値を確定し、変更内容を文書化して、カーネル、ハードウェア、または リリース- 再度切り替える。.
特定のシナリオ：コンテナ、VM、クラウド
コンテナやVMにおいて、ホストおよびゲストレベルでスワップニスを調整しています 一緒に 。Kubernetes のようなオーケストレーション環境では、ポッドの遅延を最小限に抑えるため、ワーカーノードの設定を非常に低く設定することが一般的です。 VMでは、内部で適切な値を設定していますが、ハイパーバイザーがそれに逆行しないよう注意しています。弾力的なクラウド環境では、スケーリングが効き始めるまで、控えめな値を設定することで負荷のピークを平滑化できます。また、1つのコンテナが激しいスワップ動作によってシステム全体に負荷をかけることを避けています。 プラットフォーム ブレーキがかかる。.
モニタリングとトラブルシューティング
スワップニスが適切でない場合の典型的な兆候としては、RAMに空きがあるにもかかわらずI/O負荷が高いこと、応答時間の変動が激しいこと、データベースクエリの処理が遅いことなどを挙げています。こうしたパターンは、vmstat、iostat、sar、および私のオブザーバビリティ・スタックからのメトリクスを使って確認しています。 RAMに空きがあるにもかかわらずシステムのスワップ使用率が高い場合は、通常、スワップニネスを低く設定します。RAMが不足している際にOOMログやプロセス異常終了が見られる場合は、スワップニネスを適度に引き上げるか、スワップの設定を調整します。以下の表は、スワップニネスの設定が不適切である可能性を示す症状を整理したものです。 原因 …へと導き、最初の方向性を示す。.
| 症状 | 推定原因 | 次のステップ |
|---|---|---|
| 高いI/O 空きRAMがある場合 | Swappinessが高すぎる | 価値を低下させ、効果を測定する |
| OOMイベント 負荷時 | Swappinessが低すぎる、またはスワップ量が不足している | 値を引き上げ、スワップサイズを確認する |
| 処理に時間がかかるクエリ CPUの余裕があるにもかかわらず | データベースバッファがスワップアウトされた | 0～10の範囲の値、DBバッファの分析 |
| 負荷ピーク CPUによるボトルネックなし | スワップに起因するI/Oのピーク | Swappinessを下げ、キャッシュヒットを確認する |
微細な指標を理解する
スワップニスを客観的に評価するために、カーネルのカウンタを詳しく調べてみます。 /proc/vmstat では、pswpin と pswpout が、読み込まれたページ数およびスワップアウトされたページ数を示しています。pgscan_kswapd_* および pgsteal_* は、リクレーマがどれほど積極的に動作しているかを示しています。 pgmajfault（メジャー・ページ・フォールト）が頻繁に発生している場合は、I/O負荷の高い再読み込みが行われていることを示唆しています。私はこれらの値を繰り返し確認するか、sar -B や sar -W を使用して、単なる瞬間的な値だけでなく、発生率を把握するようにしています。 vmstat 1 を使用すると、si/so（スワップイン/アウト）を把握でき、スパイクを実際のイベントと関連付けることができます。さらに、/proc/pressure/memory は、メモリ圧迫によってタスクがどの程度影響を受けているかについての評価を提供します。 ブロック (PSI)。そこが一部または全体的に上昇している場合、リクレイムが過度に積極的であるか、スワップネスが不適切であるという明確な兆候となります。.
Swappiness 0 対 1：カーネルが実際に行っていること
Swappiness=0に設定するとスワップが完全に無効化されるとよく考えられています。しかし、それは正確ではありません。0という値は、カーネルに対してスワップを可能な限り回避し、真のメモリ不足時にのみ使用するように指示するものです。 実際には、1～10の値を設定すれば非常に控えめな動作が得られますが、一部のバージョンでは0に設定すると、リクレイムフェーズの開始が遅れる代わりに、その際に激しいリクレイムが発生することがあります。 私は、レイテンシが重要なサービスに対しては通常1～5を設定し、pswpout/pswpinが実質的にゼロのままかどうかを観察しています。0の設定でバースト時にOOMイベントが発生する場合は、カーネルが急激に圧力を解放するのではなく、より早く穏やかに圧力を解放するように、値をわずかに上げます。 侵入する.
ZswapとZRAMを効果的に活用する
従来のディスクスワップに加え、プロファイルに応じてZswapやZRAMを使用しています。Zswapはスワップアウトされたページを圧縮し、必要に応じてストレージに書き込まれるまで、一旦RAMに保持します。 これによりI/Oが削減され、レイテンシが平滑化されますが、CPU負荷が増加します。CPUの余力に余裕のあるホストでは、これは より収益性の高い トレードオフ。ZRAMは圧縮されたスワップ領域をRAM上に直接用意します。これは、バースト的な負荷や、低速なI/Oよりも圧縮されたRAMを利用したい非常に小さなVMに最適です。 重要：私は意図的にどちらかのコンセプトを選択し、最速のパスが優先的に処理されるよう優先順位を設定します。その際、スワピネスは依然として制御手段となります。Zswap/ZRAMを使用する場合でも、不要なリクレイムの波は避けたいと考えています。.
ページキャッシュ、vfs_cache_pressure、およびキャッシュヒット
Swappinessは、ファイルやiノードをRAMに保持するページキャッシュと連動しています。vm.vfs_cache_pressure パラメータを設定することで、カーネルが匿名ページに対してこれらのキャッシュをどの程度積極的に解放するかを制御します。値が高すぎると、メタデータキャッシュが急速に消失してしまい、Webサーバーのパフォーマンスが低下します。 私は通常、50～100から始め、キャッシュヒット率を測定し、静的アセットやAPIレスポンスのレイテンシがどのように変化するかを観察します。 目標は、頻繁に利用されるコンテンツをRAMに保持しつつ、利用頻度の低いページがメモリを占有しすぎないようにすることです。ヒット率が良好でI/Oが低い状態が続けば、バランスは取れています。そうでない場合は、`/etc/mnt`内の`swappiness`と`vfs_cache_pressure`を調整します。 タンデム.
ダーティ・ライトバックとI/Oのピークを回避する
書き込みパスは、スワップと同様にレイテンシに影響を与えます。vm.dirty_background_ratio/bytes および vm.dirty_ratio/bytes を使用して、カーネルが書き出しを行う前に、どの程度の「ダーティ」キャッシュが生成されるかを決定します。 特に大容量RAM構成では、パーセンテージ指定では巨大なライトバックの波が発生する可能性があるため、上限を設定する際にはパーセンテージではなく*_bytes単位を優先しています。 目標は、スワップI/Oロックを引き起こす散発的な書き込みの急増ではなく、継続的かつ予測可能な書き込みを実現することです。iostatとライトバックキューを監視し、SSD/NVMeが常に一定の負荷で稼働するものの、 轢く になる。
NUMA、ゾーンリクレイム、および大規模なホスト
NUMA システムでは、メモリの局所性が重要な役割を果たします。vm.zone_reclaim_mode が有効になっている場合、カーネルはローカル NUMA ノード上のメモリをより積極的に回収しようとするため、意図しないリクレイムのピークを引き起こす可能性があります。 多くのホスティングワークロードでは、より安定した動作を実現するために、ゾーンリクレイムを無効にし、メモリ配置をスケジューラに委ねています。さらに、Transparent Huge Pages（THP）についても検討しています： データベースは、計画外のデフラグやTHPの割り当てがレイテンシの急上昇を引き起こす可能性があるため、多くの場合、THP=neverまたはmadviseの設定の方が良好に動作します。スワップニスは最適であっても、THPやNUMAポリシーが干渉すると、 カクつき.
コンテナおよびCgroupsの単位
Cgroups v2 を使用することで、ホストのスワップニス以外にも、さらにいくつかの調整手段が利用できます。memory.high は穏やかなリクレイムを促し、memory.max は厳格な上限を設定し、memory.swap.max はワークロードごとのスワップ量を制限します。これにより、個々のコンテナがスワップによってホストのパフォーマンスを低下させるのを防ぎます。 ノードではスワップニスの値を低く設定し、重要なワークロードには memory.low によって優先度を高く設定し、そのホットセットがより長く RAM に残るようにしています。Kubernetes では、ノードがスワップをどのように扱っているかに注意を払い、変更はまず非本番環境でテストしています。 重要なのは全体像です。ホストパラメータ、Cgroupのリミット、オーケストレーターが互いに整合していなければなりません。そうでなければ、負荷は単に一つのレベルから別のレベルへと移行するだけです。 他の.
展開、自動化、および再発
私は、Swappinessの変更を、他のパフォーマンス最適化と同様に、段階的に展開しています。まず、ほぼ同一のノードからなる小規模なグループ（カナリア）で適用し、その後段階的に範囲を広げていきます。systemd-sysctlや設定管理ツールにより、これらの値を再現性を持って組み込んでいます。 開始値と目標値、実施日時、対象ホストなどを記録し、 指標. 再発に備えて、あらかじめ対応する変更（例：sysctl vm.swappiness=60）を計画し、以前のsysctlファイルを保存しておきます。 メンテナンス時間帯には、変化を時間帯やトラフィックの変動と混同しないよう、意図的に典型的な負荷シナリオを測定しています。そうして初めて、意思決定の信頼性を保ち、チーム内で わかりやすい.
よくある誤解とアンチパターン
- „「Swappiness=0 に設定するとスワップが無効になります」“: いいえ、カーネルは引き続きスワップを使用していますが、その使用は極めて控えめです。.
- „「スワップを増やせば増やすほど、より安全になる」“: スワップが多すぎると、処理にかかる時間が長引くだけでなく、RAMのボトルネックを解決するどころか、かえってそれを隠してしまうことになる。.
- „「NVMeならスワッピングは問題にならない」“: NVMeは高速ですが、RAMに比べると桁違いに遅いです。レイテンシは依然として顕著です。.
- „「すべてのサーバーに共通の値」“: ワークロードには大きなばらつきがあります。測定を行わなければ、チューニングは運任せになってしまいます。.
- „「Swappinessならどんな遅延も解決する」“: 問題の原因は、キャッシュヒット、ライトバック、THP、クエリプラン、あるいはネットワークパスにあることがよくあります。.
クイックスタートのまとめ
私は通常、Webサーバーのvm.swappinessを10～20に、データベースの場合は0～10に設定し、その効果をテストして、I/O、レイテンシ、および スワップ-の割合。最終的な値はsysctlを使って/etc/sysctl.d/に設定し、変更履歴を明確に管理しています。並行して、適切なサイズ、高速なメディア、合理的な優先順位といった、一貫性のあるスワップレイアウトを確保しています。 メモリ使用率については、ページキャッシュとその挙動にも注意を払っています。この概要は、その理解を始める上で良い手引きとなります。 ページキャッシュの追い出し, 、原因分析を手伝ってくれる人で、 コンテクスト 。この方法により、安定した応答時間を確保し、スワッピングの急増を防ぎ、既存のRAMを効果的に活用することができます。.
