なぜそのようなツールがないのだろうか。メモリ2スワップ、部分的にcpulimitに似ています。
例えば
daemon.binプログラムがあります。
一時スワップファイル（1GB）を作成してみましょう。
% dd if=/dev/zero of=tmp.swap bs=1m count=1000
放射：
% cpulimit -l 10 ram2swap -f tmp.swap daemon.bin
daemon.binはRAMまたはSWAPを使用する代わりにファイルにメモリを割り当てますtmp.swap。
パフォーマンスが大幅に低下します。はい。しかし、どのくらい柔軟性がありますか。
答え1
単一プログラムの観点では意味がないため、そのようなツールは存在しません。
CPU/HDD/RAM/スワップはリソースと見なすことができます。オペレーティングシステムは、さまざまな方法でプロセス、ユーザー、コンテキストなどの間でこれらのリソースを共有できます。
オペレーティングシステムに厳格な制限を適用するように指示することが適切な特定の状況があります。
- このプログラムがメモリの60％以上を使用しないようにしてください。
- そのユーザーが必要な場合は、他のユーザーがCPU時間の20％以上を使用することを許可しないでください。それ以外の場合は、100％CPUを使用できます。
- このグループのユーザーは2つ以上のコアを使用できません。
- ...
これは実際柔軟性：管理者の希望とオペレーティングシステムの遵守に応じて、ユーザー間でリソースを共有します。
プログラムを手動でスワップに入れるのが悪いのはなぜですか？
- 基本的にカーネルの経験的方法よりも優れていると仮定しています。カーネルはすでにスワップ空間自体を処理します。デーモンが長時間アクティブでなく、オペレーティングシステムのRAMが不足すると、最終的にスワップ状態になります。
- AFAIK、スワップ領域は実行可能ではありません。実行する前に、スワップ領域の内容をRAMで取得する必要があります。したがって、RAMで最初のタイプのプログラムを実行し、スワップで2番目のタイプのプログラムを実行したい場合は、すぐに停止すると機能しません。
- 「はい、しかし特定のデーモンは月に2回呼び出されます。RAMでは必要ありません」これが真であれば、RAMが不足するとカーネルがスワップ状態になります。
- 「メモリが足りなくなるのを待たなければならないのはなぜですか？」スワップに物を入れて取り出すことは、特に一般的なハードドライブの場合には高価です。システムがすべてをRAMに保存できる場合は、これを行うのが最善です。一時的に何かを強制的に交換すると、システムの反応性が低下します。他の「ファーストクラス」デーモンも一部のHDD IOを実行する可能性が高いため、これらのデーモンも速度が遅くなります。 「2番目のタイプ」デーモンが起動し、RAMに配置する必要がある場合でも同じことが起こります。
これで、ユーザーはなぜ魔法のコマンドラインを使用してプログラムをスワップに入れることができないのですか？
- ユーザースペース（非カーネル）の観点からは、スワップに何を入れるべきかは明確ではありません。あなたのプログラムはに接続されています
libmylib.so。このプログラムも交換する必要がありますか？だから何libc.so？ - 実際に予想される動作は何ですか？デーモンをスワップに直接入れたいですか？ただし、一部の初期化操作を実行する必要があります。そうですか？その後、ロードするとRAMに戻ります。
- デーモンが廃止され、安全に再スワップできることをどうやって知ることができますか？
- スワップ領域に直接送り返す必要がありますか、それとも待つ必要がありますか？それ以外の場合は、デーモンがスリープするたびにスワップに入り、目が覚めるたびにRAMに戻ります。たとえば、デーモンがコンピュータの時計を更新している場合は、数時間の交換に備えてください。
- ...
簡単に言えば、これを処理するにはコアが必要で、これがコアが実行する作業です。ほとんどの要件に対して交換性を調整するだけでレスポンシブシステムを実現できます。
今本当に欲しいなら
（源泉：Freakoutnation.com） 、カーネルはを使用して動作しますcgroups。でデーモンにmax memとmax mem + swapを設定して、必要なものを取得できますcgroups。各プログラムの交換性を設定すると、より合理的な結果が得られます。しかし、どちらにしても良い考えではなく、もはや進行しません。これ説明として。
答え2
説明した状況は次のとおりです。プロセスで使用されるRAM（仮想メモリではなくRAM）の量を制限する機能があります。このRLIMIT_RSS制限は、プログラムの常駐セットサイズ、つまりプロセスが常駐するメモリ部分（スワップアウトとは反対）の上限を設定します。ただし、Linuxでは実装されていません。
RLIMIT_RSS一部の古いUnixシステム（BSDのみ？）には存在しますが、多くの最新システムでは削除されました。存在するLinux、2.4シリーズにのみ存在します（完全には機能しません）。ソラリスでは落ちる遠い過去のある時点（Solaris SunOSがBSDからSystem Vに切り替えたとき？）。FreeBSDもっとそうです。
RLIMIT_RSSなぜ削除されたのかわかりません。アランコックス2006年に彼はこう言ったことがある。
Linuxの元のバージョンでは、計算コストがかからないRSSを追跡する方法がなかったため、これを実施しませんでした。現在、mmsはRSS調整を実装できますが、ユーザーがRSS制限をより低く設定し、スワップスラッシングを多く発生させる場合、これがどのような影響を与えるかは疑問です。
効果的に実行できる方法が見つかった場合は、そうしてください。
このトピックはそれ以来何度も言及されていますが、私が知っている限り、Linuxカーネルはまだパッチを受け入れていません。
プロセスの物理メモリ使用量に制限を加える理由の1つは、プロセスが使用する物理メモリの量を定義するのが難しいからです。それでは、スタックとヒープ（交換されていない部分）を数えましょう。メモリマッピングファイルはどうですか？プロセスの物理メモリ使用量を測定するには、マップされたファイルによって使用されるキャッシュを計算する必要があります。共有ライブラリと他の共有マッピングはどうですか？単一のプロセスで使用する場合は当然計算する必要がありますが、複数のプロセスで使用している場合、どのプロセスがどの部分を使用しているのかを知ることは困難です。
単一プロセスの物理メモリ使用量を制限することは意味がありません。リソース制限が継承されることを考えると、各子孫はできるだけ多くの物理メモリを使用できます。プロセスグループの物理メモリの制限を許可する方が合理的です。 Linuxにはこの機能が組み込まれています。cgroup、プロセスとその子がコンテナで実行される部分的に仮想化されたシステムで、独自のファイルシステムルート、独自のネットワークコントローラ、独自のリソース制限などを持つことができます。cgroup メモリ使用量制限（RAMとスワップ領域の使用の制御）はパラメータを介してmemory.limit_in_bytes実行できます。memory.memsw.limit_in_bytesドキュメントでは、グループ間で共有されるページが多少ランダムな方法で割り当てられることを警告します（「共有ページは最初のタッチ方法に基づいて計算されます。ページを最初にタッチするcgroupはページを計算します」）。そこ他の方法かもしれません制限は厳密には適用されません。
要件の他の部分は、プロセス用の専用スワップファイルを持つことです。これにはかなり複雑なカーネルが必要です。両方のプロセスに異なるスワップスペースが割り当てられている場合は、ページを共有できることに注意してください。どのスワップファイルが使用されますか？一方、この機能はプロセスの観点から非常に簡単に達成できます。つまり、ファイルをメモリにマップします。共有ページの場合は、まだファイルがあります。別の利点は、プロセスのさまざまな領域でさまざまな「スワップ空間」を使用できることです。