私はあらゆる種類の「ブロック」に非常に敏感で応答性が非常に高く、ほとんどの場合、完全なレイテンシを維持する必要があるリアルタイムネットワークアプリケーションを持っています。
残念ながら、アプリケーション自体（マルチスレッド）はメモリを大量に消費するため、約6 GBのRAMが必要です。
システムには8GBのRAMと2GBのスワップスペースがあります。いくつかのパフォーマンスの問題、スワップイベントに関連するアプリケーションの待ち時間の増加（15秒ごとにgrafanaとnode_exporterを使用してOSを監視する）が観察され、同時に深刻な待ち時間が発生してOSが一部のページをスワップしていました（まだ2GBの空き容量あり）。スペース）メモリ）。
私はLinuxカーネルVMサブシステムを非常によく知っているので（Mel Gormanの著書「Linux®仮想メモリマネージャについて」を読んでいます）、これをアクティブページを積極的に置き換えるOSと組み合わせて、より多くのFSキャッシュ/バッファリングを実現しました。アプリケーションの待ち時間に大きな影響を与えない場合は気にしないでください。
カーネルがメモリ不足の透かしに達したとき、最後の手段としてのみスワップを有効にしましたが、役に立ちませんvm.swappiness = 0でした。ほぼ同じサイズの小さなメモリチャンクを交換し続けます。 30分ごとに1回、アプリケーションの待ち時間に深刻な影響を与えます。
有用な唯一の方法は、スワップを完全に無効にすることでした。そうした後、遅延の問題は再び発生しませんでした。ただし、アプリケーションが一時的に合計使用量8 GBにアクセスするためのより多くのメモリを必要とする不幸な状況が発生した場合、OOM Killerは現在一部の非アクティブページを置き換えるのではなくメモリをシャットダウンするので問題になります。麻痺。
だから、2つの質問があります。
- これらの小規模な交換イベントがアプリケーションの待ち時間に大きな影響を与えるのはなぜですか？私が理解したように、スイッチはとにかく非アクティブメモリページを削除します。スイッチがメモリを移動するときにRAMに存在しないか、移動中のページにアクセスしようとしなくてもプロセスは停止しますか？
- 必要な場合にのみカーネルを強制的に置き換える方法はありますか？例えば。 - RAM> 1GBがまだ利用可能な場合は交換しませんか？
ベストアンサー1
残念ながら、カーネルが実際に何をしているのかについての答えはありません。ただし、特定の問題を解決するのに役立ついくつかの点があります。
- より多くのメモリを確保
- 少ないRAMを使用して最適化
- ディスクと交換するのではなく、ZRAMと交換すると、速度がはるかに高速になります。デフォルトでは、ページを交換すると、ディスクに書き込むのではなくメモリに圧縮するだけです。圧縮アルゴリズムのオーバーヘッドがあってもはるかに高速です。
- まだ使用していない場合は、RT-linuxカーネルパッチセットをお試しください。 「リアルタイムLinux」プロジェクトの重要な点は、待ち時間の目標を見逃すと誰かが死ぬアプリケーションを実行することです。したがって、ここでは、この種の致命的な待ち時間の問題は発生しないと仮定する。少なくともそうではないことを願っています。それはひどいでしょう。ほとんどのディストリビューションでは rt カーネルを使用できます。
- LE9カーネルパッチは、特にメモリ不足の状況でスワップ動作を処理するため、ある程度関連性がある可能性があります。 Linuxカーネルは、実行可能なコード/ライブラリを含むページをデフォルトのスワップデータと見なし、最初に置き換えます。その後、プログラムはそのコードの実行を開始し、ページエラーが発生し、ページの交換中に停止してから続行します。私が理解しているように、LE9パッチは実行可能ページがすぐに交換されないように保護し、メモリが不足したときにそのページが破損するのを防ぎ、システムがハングするのではなく正常に処理できるようにします。
交換すればどうなるかわからないけど出る、交換するたびにプロセスが確実に停止します。存在する、これがページフォルトが処理される方法です。一部のメモリにアクセスしようとしていますが、ページがロードされず、カーネルがすべてを停止してページをロードし、要求したときにメモリがないことを望むようにプログラムを再起動します。私は何かが交換されると最終的に再び交換され、プロセスが確実に中断されると仮定します。これが起こっている可能性があります。