...
ウェブホスティングのロゴ

スワップ使用サーバー：ホスティングにおけるパフォーマンスの最適化

ホスティングのワークロードが負荷でストールしないように、スワップ使用サーバーを目標通りに制御する方法を紹介する。 演技 トリガーの問題。その原因、重要な数値、スワップネス設定、推奨サイズ、そして実践的なチューニングの手順について説明する。 メモリー スワッピング・ホスティング。.

中心点

  • スワップネス 削減：積極的なアウトソーシングを避ける
  • サイズ チェックするスワップをRAMとワークロードに合わせる
  • 入出力 守る：SSDの配置、Zswap/ZRAMの意識的な使用
  • モニタリング を確立する：ページフォルト、kswapd、レイテンシ
  • ワークロード adapt：キャッシュとDBバッファのバランス

スワップの本当の効果 - スワップがあなたのスピードを鈍らせるとき

スワップは、めったに使わないページをSSDやHDDに移動させることで物理RAMを拡張し、OOMキラーからプロセスを保護する。 バッファ 与える。Linuxは、アクティブなページにより多くのスペースを与え、ページキャッシュを維持するために、臨機応変にオフロードを行う。 入出力-ロード。システムがRAMとスワップを頻繁に切り替えると、すぐにスラッシングのリスクが発生し、その結果レイテンシが顕著になります。特にPHP、データベース、Node.jsを使ったヘビーなウェブホスティングでは、キャッシュ、PHPワーカー、DBバッファがメモリを奪い合う。そのため、私はセーフティネットとしてスワップを利用できるようにしていますが、通常の運用ではスワップの使用を最小限に抑えています。.

高スワップ使用の兆候を認識する

まずチェックする 無料 -hと vmstat, というのも、スワップイン/スワップアウト率が高い場合、ボトルネックが発生していることを示すからである。スワップ・イン/スワップ・アウト率が高ければ、ボトルネックになっていることを示すからである。しかし、ページフォールトレートとIOキューが増加すると、アプリケーションのレイテンシが増加し、リクエストが遅くなる。ログを見ると、スワップがピークに達すると同時に、ビジー状態のワーカーや遅いクエリが発生していることがわかる。仮想メモリの基礎知識については、以下のコンパクトな入門書を参照されたい。 仮想メモリ, これはカテゴリー分けの助けになる。.

メモリ・スワップ・ホスティングの利点とリスク

私はスワップを使ってRAMのピークを緩和し、重要なサービスを稼働させている。 失敗 が回避されます。つまり、小規模のVPSインスタンスであれば少ないRAMで管理でき、IO負荷が制限内に収まる限り、ユーロのコストを削減することができます。しかし、スワップアウトが多すぎると、SSD/NVMeは明らかにRAMに遅れをとり、リクエストは停止します。さらに、圧縮（ZRAM）にはCPU時間がかかる。したがって、スワップは私にとって代替ではなく、私が積極的にコントロールするセーフティネットなのだ。.

スワップネス：最も重要な調整ネジ

カーネル変数 vm.swappiness (0-100、デフォルトは通常60)は、システムがどの程度早くページをオフロードするかを制御します。一時的に sysctl vm.swappiness=10, 永久に書く vm.swappiness=10 に於いて /etc/sysctl.conf. .SSDホストでは、この結果スワップが減り、ページキャッシュ用のスペースが増える。その後、IO、レイテンシー、作業セットをモニターして効果を確認する。主要な数値が安定したままであれば、設定を維持し、後の監査のために変更を文書化する。.

一般的なサーバーに最適なスワップサイズ

大きすぎるファイルを見つけると、RAMや作業量、ハイバネーションに合わせてスワップサイズを調整している。 メモリ と小さすぎるファイルはバッファを減らします。ハイバネーションのない一般的なホスティングサーバーでは、私は適度な値を計画し、巨大なスワップボリュームよりもより多くのRAMを優先します。乏しいVPSインスタンスでは、本格的なアップグレードが可能になるまで、1.5～2倍のRAMが理にかなっています。RAMに余裕がある場合、クラッシュを避けるためにスワップ領域を小さくしても利用できることがよくあります。私は以下の表を出発点として、実測値に応じて調整しています：

RAMサイズ ハイバネーションなしでスワップ 冬眠と交換
≤ 2 GB 2x RAM 3x RAM
2-8 GB = RAM 2x RAM
8-64 GB 4～8 GB 1.5倍 RAM
> 64 GB 4 GB 推奨しない

スワップの配置と高度なテクニック

私はパーティションよりもスワップファイルの方が好きだ。なぜなら、サイズを動的に調整でき、より速く変更できるからだ。 生きる ゴー。スワップ領域が別のSSDストレージ上にあれば、OSとのIOの競合が少なくなる。非常に小さなVMの場合は、IOを減らすテストとしてZswapやZRAMを使うが、CPUの使用率には注意する。オーバーコミットをきれいに制限し、どのプロセスもマシンをスラッシングに追い込まないようにサービスの制限を設定する。最終的に重要なのは、測定可能な効果です。待ち時間が減り、IOが静かになり、応答時間が一定になります。.

モニタリング：どの数字が本当に重要か

私は、RAMの使用率、ページキャッシュ、スワップイン・アウト、以下のアクティビティを測定している。 kswapd とIOキューは、これらの値が早い段階で私にシグナルを送るからだ。スワップの動きが増えたら、アプリケーションの待ち時間やクエリー時間と関連付ける。また、高価なメモリアクセスを認識するために、マイナー／メジャーページフォールトをチェックする。バッファ戦略を理解するために、私はこのガイドを使っている。 バッファとキャッシュの使用率. .メトリックスとログが一貫した圧力を示しているときだけ、私は介入して設定を変更する。.

カーネルはどのようにページを選択するのか：Reclaimをさらに深く見る

Linuxは匿名ページ（ヒープ/スタック）とファイル対応ページ（ページキャッシュ）を区別している。どちらもLRUリスト（active/inactive）にアタッチされている。メモリが圧迫されている場合、カーネルはまず、非アクティブなファイルベースのページを（ディスクからリロードできるので素早く）廃棄しようとする。アクティブな匿名ページが多すぎる場合は、スワップに移動させる必要がある。これはより高くつく。 vm.vfs_cache_pressure を使用すると、デントリ/コードの破棄が高速化され、容量が空きますが、ウェブサーバーでのファイルアクセスが増える可能性があります。私は通常50-100程度に保ち、キャッシュのヒット率とレイテンシの変化を観察しています。.

私は、ライティング・パスに影響を与える。 vm.dirty_background_bytes/vm.dirty_bytes (またはその比）。高すぎるダーティ・リミットは問題を先送りするだけで、後で大きなライトバックを発生させ、スワップ再生速度を低下させる。大容量RAMシステムでは、バイトベースの制限がより正確に機能するので、私はバイトベースの制限を好む。もう1つの回避策は vm.min_free_kバイトこの値が低すぎると、再生が多忙なサイクルに陥り、高すぎるとRAMを浪費する。dmesgで „low free watermarks “と常に表示されない限り、私は通常この値をディストリビューションのデフォルトのままにしておく。.

PSIとkswapd：先行指標を正しく解釈する

古典的な測定基準に加えて、私は次のような測定基準を使っている。 圧力失速情報 に於いて /proc/pressure/memory. .高い いくつか 或いは フル 数秒以上の値は、タスクがメモリを待っていることを示している。これは、ユーザーがレイテンシーに気づく前の最初の兆候であることが多い。同時に、私は kswapd数パーセント以上上昇すると、Reclaimは熱くなる。と vmstat 1 私は次のことに注意を払っている。 シー/然れば (スワップ・イン/アウト）と r/b (ラン／ブロックキュー）。常に高い 然れば-価値観の拡大 b-そして私は一貫して介入する。.

Cgroups v2とsystemd: スワップを意図的に制限する

マルチテナントやコンテナ環境では、1つのサービスがすべてのリザーブを食いつぶしてしまうのを防いでいる。cgroups v2では メモリ.max (ハードリミット）、, メモリ.high (ソフトチョーク）と メモリスワップ最大 (スワップ制限）。systemdではサービスごとに MemoryMax=, MemoryHigh= そして MemorySwapMax= をオーバーライドします。つまり、PHP-FPM がシステム全体をスワップ状態にすることはできず、 データベースは反応し続けるということです。バーストでは、狭い メモリ.high プラス・モデラート MemorySwapMax=, ハードなOOMのリスクを冒す代わりにね。私は各サービスごとにこれらの制限を文書化し、レビューの過程で常に最新の状態に保つ。.

スワップファイルの作成、拡大、優先順位付けをきれいに行う

実際には、素早く再現可能なステップが必要だ：

  • スワップファイルを作成する： fallocate -l 8G /swapfile && chmod 600 /swapfile && mkswap /swapfile
  • アクティベートする： スワポン /スワップファイル; 恒久的に /etc/fstab をもって /swapfile none swap sw,pri=5 0 0
  • サイズを調整する： スワップオフ /スワップファイル, fallocate -l 12G /swapfile, mkswap /swapfile, スワポン /スワップファイル
  • マルチスワップ：より高速なNVMeとより高いスワップ性能 プライ 優先順位をつける。 swapon --show --output=NAME,PRIO,SIZE,USED コントロール

IOが非常に弱いシステムでは、スワップ・サイズを小さくするか、スワップをより高速なデータ・キャリアに配置する方が、システムがゆっくりと「死ぬまでスワップし続ける」よりはましだ。.

ZswapとZRAM：圧縮が本当に役立つとき

Zswapは、RAMでバックアップされたプールでスワップアウトされるページを圧縮し、物理IOを削減する。これはSSDを保護するが、CPU時間を犠牲にする。コア数の少ないVMでは、まずlz4（高速で弱い圧縮）をテストし、CPUピークが増加するかどうかを観察する。IOがほとんどない状態を維持するために、非常に小さなインスタンスではZRAMを選択的に古典的なスワップに置き換える。新たなボトルネックを作らないために、圧縮は意図的に小さくしている（例えばZRAMは25-50% RAM）。CPUバウンドのワークロードがつまずき始めたら、すぐにこの最適化を見直す。.

THPとフラグメンテーション：隠れた遅延のブレーキ

Transparent Huge Pages (THP)はJVMやデータベースを助けるだけでなく、混在ホスティング環境での再生やスワップの負担を軽減することができます。私はTHPを マドヴァイズ, 明示的に使用するワークロードだけが恩恵を受けるようにするためだ。メモリの断片化が顕著になった場合は、メモリ集約型サービスのローリング再起動を計画し、ヒープが破壊されないようにする。MySQL/MariaDBについては、Linuxのページキャッシュが飢えないように、InnoDBのバッファプールが総メモリに対して十分大きいかどうかもチェックする。.

NUMAとマルチソケットホスト

NUMA は大規模なベアメタルホストで役割を果たす。アンバランスなメモリアクセスはレイテンシを増加させ、リクレイムを加速させる。ワークロードを numactl --interleave=all またはノードごとに特定のサービスをピン留めします。多くのページキャッシュアクセスを引き起こすクリティカルなサービス（Nginxなど）は、データパスの近くに置いています。メモリを大量に消費するバッチジョブはカプセル化し、必要に応じてcgroupの制限を厳しくして、NUMAのオーバーフローがシステム全体をスワップに押し込まないようにしています。.

プロセス診断：誰が本当に交換するのか？

システム・メトリクスがアラームを発した場合、私はプロセス・レベルで原因を特定する： Smem -knr はPSS/USS（現実的なメモリーシェア）を示している、, pmap -x <pid セグメント分布で /proc//ステータス 私はチェックする ブイエムアールエスエス, ブイエムスワップ そして oom_score_adj. .高い ブイエムスワップ-LRUに向かないパターン（匿名ページが多く、ほとんど使われていない）の値は、制限やコードの最適化の候補となる。また pidstat -r 1, プロセスごとのフォールト・レートを確認し、アプリケーションのレイテンシーと比較する。.

ランブック、SLO、エスカレーションレベル

ホストクラスごとに明確な制限値を定義しています。たとえば、kswapd-CPU < 5分平均で5%、メジャーフォルト < 通常運用で50/コア、PSIメモリ いくつか < 10% over 60s。もし2つのメトリクスが同時に壊れた場合、私は次のような順序で介入する：スワッピネスのチェック、ワーカー／バッファの一時的なスロットル、スワップの配置と優先順位の調整、圧縮の（解除）有効化、必要であればRAMの増加。これらのランブックは私のインシデント対応の一部であり、チームが再現可能な方法で行動できるようにするためだ。 レイテンシー 制御下に留まる。.

トラブルシューティング：典型的な原因と迅速な解決策

スワップレートが上がったら、まずメモリを大量に消費するサービスをチェックし、次のように制限する。 cgroups またはサービス設定。それから、PHPワーカーが多すぎないか、DBバッファが大きすぎないか、ページキャッシュが小さすぎないかをチェックする。スワップを減らし、一時キャッシュを整理し、ログのローテーションをピーク時からずらします。IOキューが恒常的に高いままなら、スワップを再配置するか、IO競合を最小化するためにスワップを減らす。それでも不十分な場合は、RAMを増やし、レイテンシが低いレベルで安定するまで再度測定する。.

PHP、データベース、Node.jsのチューニング

PHPでは、フルページまたはOPcacheのヒットを最大化することで、コンパイルを繰り返すために使用するRAMを少なくしている。 応答時間 が減少する。MySQL/MariaDBでは、バッファプールとクエリキャッシュとページキャッシュのバランスをとり、二重キャッシュを避けるようにしている。Node.jsでは、ヒープに制限を設け、以下のようにガベージコレクションを監視している。 イベントループ が衰えることはない。また、定期的にサービスを再起動し、リークを検出するロールアウトによって、メモリの断片化を防いでいる。を簡単に詳しく見てみよう。 メモリの断片化 このような忍び寄る問題をより迅速に発見するのに役立つ。.

コンテナとホスティングスタック：実例

コンテナ環境では、ポッドやサービスごとにハードなメモリ制限を設定し、 適度な量のスワップしか許可しません。PHP-FPMの場合は、ワーカーあたりのメモリ（RSS）とページキャッシュのヘッドルームを計算します。例: 512 MB RAM、30 MB/ワーカーの実質消費量 - ならば、20ワーカーではなく、8-10ワーカーが現実的です。 Node.jsの場合は、以下のように設定します。 --最大古いスペースサイズ GCに負担がかからないように、またカーネルが匿名メモリーを積極的にスワップしないように、物理的な上限を意図的に下回っている。データベースについては、固定予算を計画し、可能な限りウェブ層から分離し、OSにファイルキャッシュのための十分なスペースを与える。.

コスト、ハードウェア、RAMアップグレードのタイミング

私はユーロで等価値を計算する：スワップ印刷が恒久的なレイテンシを生むなら、追加RAMはすぐに価格を正当化し、実際のレイテンシを生む。 パフォーマンス. .NVMeはIOレイテンシを削減するが、揮発性メモリの代わりにはならない。ハードウェアを拡張する前に、スワップ、バッファ、ワーカー数を最適化して効率を上げる。利用率が高いままであれば、スワップだけを増やすのではなく、賢明な段階を踏んでRAMの増設を計画する。この順序は、間違った投資を防ぎ、後の比較のための明確な測定点を与えてくれる。.

チェック：15分で使用サーバーを入れ替える

私は次のように始める。 free -h, vmstat 1 と確認する。 スワップ-移動、ページフォルト、IOキュー。それから vm.swappiness=10, ロード sysctl で、主要人物を5分間観察する。適合すれば、その設定をメモし、現在の状態を記録する。次のステップでは、ページキャッシュを置き換えるワーカー数とDBバッファを修正します。最後に、ユーザーが気づく前に異常値を警告するアラームを作ります。.

簡単にまとめると

私はスワップをセーフティーハーネスとして使っているが、その使用量は抑えている。 レイテンシー が爆発することはなく、性能上の問題も発生しない。RAMと作業負荷に見合ったスワップサイズと組み合わせることで、賢明なスワップ性を維持することができる。私はkswapd、ページフォールト、IOキューを監視し、アプリケーションログと値を比較し、早めに対応します。小規模なVPSの場合、短期的にはメモリー・スワップ・ホスティングがプレッシャーを和らげます。この順序に従うことで、サーバーの応答性を維持し、ダウンタイムを減らし、予算を守ることができます。.

現在の記事