RAM）の代わりにFILEを強制的に使用するツール
パーツのcpulimitに似た、ram2swapのようなツールがなぜないのか疑問に思います。
例えば。
プログラムdaemon.binがあります。
一時的なスワップファイル（1 Gb）を作成しましょう：
% dd if=/dev/zero of=tmp.swap bs=1m count=1000
打ち上げ：
% cpulimit -l 10 ram2swap -f tmp.swap daemon.bin
RAM使用法またはスワップ）の代わりに、daemon.binはtmp.swapファイルにメモリを割り当てます。
はい、パフォーマンスが大幅に低下します。しかし、これはどのように柔軟です。
単一のプログラムの観点からは意味がないため、そのようなツールはありません。
CPU/HDD/RAM /スワップをリソースと見なすことができます。これらのリソースは、プロセス、ユーザー、コンテキストなどの間で、オペレーティングシステムによってさまざまな方法で共有できます。
特定の状況では、オペレーティングシステムにハード制限を適用するように指示するのが理にかなっています。
- このプログラムがメモリの60％以上を使用することを許可しないでください。
- 別のユーザーが必要とする場合は、このユーザーがCPU時間の20％を超えて使用することを許可しないでください。それ以外の場合は、100％CPUの使用を許可します。
- このグループのユーザーが3つ以上のコアを使用することを許可しないでください。
- .。
これにより、実際の柔軟性が提供されます。管理者の希望に応じてリソースがユーザー間で共有され、OSが準拠します。
プログラムを手動でスワップするのはなぜ良い考えではないのですか？
- 基本的に、カーネルのヒューリスティックよりも優れていると想定しています。カーネルはすでにスワップスペースを単独で処理しています。デーモンが長期間アクティブ化されておらず、OSにRAMがない場合、デーモンは最終的にスワップに入れられます。
- AFAIK、スワップは実行可能ではありません。実行する前に、スワップの内容をRAMに取得する必要があります。したがって、ファーストクラスのプログラムがRAMから実行され、セカンドクラスのプログラムがスワップから実行されることを考えていた場合：今すぐ停止してください。それは機能しません。
- 「はい。ただし、その特定のデーモンは月に2回呼び出されます。RAMには必要ありません」。それが本当なら、RAMが不足しているとカーネルはスワップに入れます。
- 「なぜRAM不足しているのか？」スワップの出し入れは、特に古いHDDの場合、非常にコストがかかります。システムがすべてをRAMに保持できる場合は、そのままにしておくことをお勧めします。スワップに何かを強制すると、当分の間、システムの応答性が低下します。他の「ファーストクラス」デーモンもおそらくHDD IO）を実行するはずなので、それらも「2ndclass」デーモンが起動してRAMに入れる必要がある場合も同じです。
では、なぜユーザーは魔法のコマンドラインを使用してプログラムをスワップに入れることができないのでしょうか。
- ユーザースペース（カーネル以外）の観点から、スワップに何を入れるべきかは明確ではありません。あなたのプログラムは
libmylib.soにリンクされていますが、それもスワップに入れるべきですか？そして、libc.soはどうですか？ - 実際に意図された動作は何ですか？デーモンを直接スワップに入れたいですか？しかし、初期化作業が必要になりますね。その後、ロードされるとすぐにRAMに戻ります。
- デーモンが使用されなくなり、再び安全にスワップに入れることができることをどのように知ることができますか？
- 直接スワップに送り返す必要がありますか、それとも少し待つ必要がありますか？それ以外の場合、スリープするたびにデーモンはスワップに入れられ、ウェイクアップするたびにRAMに戻されます。たとえば、デーモンがコンピューターの時計を更新する場合は、何時間も交換する準備をしてください。
- .。
要するに、あなたはそれを処理するためにカーネルを必要とします、そしてこれはまさにそれがすることです。ほとんどのニーズでは、応答性の高いシステムを実現するには、スワッピングを微調整するだけで十分です。
さて、あなたが本当にしたいのなら 
（出典： freakoutnation.com ） 、カーネルはcgroupsを使用してこの「柔軟性」を提供します。 cgroupsでデーモンのmaxmemおよびmaxmem + swapを設定することにより、必要なものを取得できます。プログラムごとのスワッピングを設定することで、より適切な結果を得ることができます。しかし、どちらにしても、それは良い考えではなく、説明として this 以上に進むことはしません。
あなたが説明するもののようなものがあります：プロセスによって使用されるRAMの量を制限する機能があります（仮想メモリではなくRAM）。RLIMIT_RSS制限セットプログラムの常駐セットサイズの上限。つまり、（スワップアウトではなく）メモリに常駐するプロセスのメモリの部分。ただし、Linuxには実装されていません。
RLIMIT_RSSは一部の古いUnixシステム（BSDのみ？）に存在していましたが、多くの最新システムから削除されました。 Linux では、2.4シリーズにのみ存在していました（完全に機能していませんでした）。 Solarisでは、遠い過去のある時点で ドロップされました Solaris SunOSはBSDからSystemVに切り替えました、多分？）。 FreeBSD はまだそれを持っているようです。
RLIMIT_RSSが削除された理由がわかりません。 Alan Cox は2006年にこう言っています：
Linux用の元のmmは、計算コストがかからないRSSを追跡する方法がなかったため、強制しませんでした。現在のmmはおそらくRSS制限を実装できますが、ユーザーがRSS制限を低く設定し、スワップスラッシングを大量に発生させた場合に、これがどのような影響を与えるかについては疑問が残ります。
あなたがそれを効率的に実装する方法を見つけることができるなら、それを選んでください。
それ以来、このトピックは何度か取り上げられましたが、私が知る限り、Linuxカーネルへのパッチは受け入れられませんでした。
プロセスの物理メモリ使用量に制限を適用する理由の1つは、プロセスが使用している物理メモリの量を定義するのが難しいことです。 OK、スタックとヒープ（スワップアウトされていない部分）を数えます。メモリマップトファイルはどうですか？プロセスの物理メモリ使用量を測定するには、プロセスがマップするファイルによって使用されるキャッシュをカウントする必要があります。共有ライブラリやその他の共有マッピングはどうですか？それらが単一のプロセスで使用されている場合は、明らかにそれに対してカウントする必要がありますが、複数のプロセスで使用されている場合、どのプロセスがどの部分を使用しているかを知ることは困難です。
単一のプロセスの物理メモリ使用量を制限することは、それほど意味がありません。リソース制限が継承されるとすると、各子は同じ量の物理メモリを使用できます。一連のプロセスの物理メモリに制限を設けることは、もう少し理にかなっています。 Linuxには、この機能が cgroups に組み込まれています。これは、プロセスとその子孫が、独自のファイルシステムルート、独自のネットワークコントローラー、独自のリソースを持つことができるコンテナーで実行される部分的な仮想化システムです。制限など。 cgroupのメモリ使用量 は、memory.limit_in_bytesパラメータで制限できます（memory.memsw.limit_in_bytesはRAM =プラススワップ）。ドキュメントは、グループ間で共有されるページがやや任意の方法で割り当てられることを警告しています（「共有ページはファーストタッチアプローチに基づいて会計処理されます。ページに最初にタッチするcgroupはページを会計処理します。」） 。 制限が厳密に適用されない他の方法 があるかもしれません。
あなたが求めているものの他の部分は、プロセス専用のスワップファイルを持つことです。これには、カーネルにかなりの複雑さが必要になります。ページは共有できることを忘れないでください。 2つのプロセスに異なるスワップスペースが割り当てられている場合、どのスワップファイルを使用しますか？一方、この機能はプロセス側からかなり簡単に実装できます。ファイルをメモリにマップします。共有ページの場合、まだ1つのファイルがあります。副次的な利点として、プロセスのさまざまな領域でさまざまな「スワップスペース」を使用できます。