読み取り/書き込みジョブをキューに入れることはできますか？
HALとサーバーを共有しています。サーバーには32GBのメモリがあります。
1 GBを超えるメモリを使用することはめったにありません。使用する場合は、一度に数分間使用するので、そのようなジョブを列の最後に送信してもかまいません。
HALは大きなファイルの読み取り/書き込みを行います（例：gunzipを使用）。これは、memory CPUの最大100％を、断続的に、何時間もかかる可能性があります。これは通常一晩で行われますが、実行すると、cdなどの単純なコマンドでも30秒かかり、emacsを開くのに数分かかる場合があります。
<< 1GBを使用するプロセス（テキストエディタなど）で使用するために1GBを予約できるようにしたいと思います。また、HALの邪魔にならないようにしたいので、これが問題になる理由はありません。
HALによると、キューイングシステム（PBSなど）を使用して、読み取り/書き込みの優先度を低くすることはできません。大きなジョブが実行されているときに常に1GBのメモリを使用できるようにします。彼の言葉で：
データが大きいため、gunzipに使用されるスクリプトは、可能なすべてのプロセッサを妨害します...キューイングはこれを解決しません...（そのサーバー）から（このサーバー）へのファイルの転送中に、インフレーションステップは多くの読み取りを行います/書く
なぜキューイングでこの問題を解決できなかったのですか？どのような可能性？
ジョブキューイングシステムを使用するか、カーネルのスケジューリングアプローチを変更することができます。
これらのオプションは無視し、 ionice -を使用することをお勧めします。具体的には、ボブが優先度を下げるために使用することをお勧めします。メモリの問題ではなく、ディスクアクセスの問題が発生しているようです。
通常 Nice は、ディスクの優先度に間接的に影響するため、オプションの場合もあります（ioniceのマニュアルページから： "ベストエフォートクラス内の優先度は、プロセスのCPUニースレベル：io_priority =（cpu_Nice + 20）/ 5。 "）ソフトウェア atop は、ボトルの概要を取得するのにも非常に便利です。 -ネッキングとそれが通常の場合IOまたは問題のディスクへのスワップ。
ボブは大きなファイルの読み取り/書き込みを行います（例：gunzipを使用）。これは、メモリの最大100％を、断続的に、何時間も使用する可能性があります。これは通常一晩で行われますが、実行すると、cdなどの単純なコマンドでも30秒かかり、emacsを開くには数分かかる場合があります。
最初のgzipとgunzipは、思ったとおりに機能しません。gzipで使用されるアルゴリズムはブロックベースですが、チャグすると少し大きくなる可能性があります。大きな圧縮ファイルを介して、1GBの.gzファイルを解凍しても、私のマシンでは約15MのRAM（合計プロセスサイズ）しか消費しません。
第二に、全体ファイルをRAMに吸い込んでいない限り、大きなファイルを読み書きするだけでは多くのメモリを消費しません-OSはデータを保持している可能性がありますファイルシステムキャッシュですが、プログラムがそのRAMを必要とする瞬間にキャッシュデータが削除されます。プログラムの作業メモリに保持されているデータのみが「メモリプレッシャー」（使用されたRAM、およびその他のいくつかの要因）にカウントされます。
<< 1GBを使用するプロセス（テキストエディタなど）で使用するために1GBを予約できるようにしたいと思います。また、ボブの邪魔にならないようにしたいので、これが問題になる理由はありません。
オペレーティングシステムのポケットベルの裏をかく試みをやめましょう：カーネルはタスクを交換して、現在実行している人がRAMで動作するようにします。はい、これは、次の場合にディスクにアクセスすることを意味します。使用可能な量よりも多くのRAMを使用します。解決策は、実行するプログラムの数を減らして使用するRAMの量を制限するか、RAMを追加することです。 。
「予約」の概念RAM OS設計の観点からは根本的に欠陥があります。他のアクティビティを実行することはできませんが、Bobのプログラムは「予約済み」RAMにアクセスできないため、現在は（たとえば）1KBが必要な場合、Bobのプログラムは、RAMにデータをページングしたり、RAMからデータをページングしたりすることで、一定のディスクヒットを発生させ、パフォーマンスは低下します。
ボブのRAM使用量（ulimit）を人為的に制限することはできますが、彼がハード制限に達すると、彼のプログラムはおそらくうまく反応しません（考えてみてください：malloc(): Unable to allocate XXXXX bytes follow不潔な出口によって）。
コメントで言及されているrvsのように、環境を仮想化し、BobのプロセスがVMで使用可能なリソースにのみアクセスできるようにすることができますが、これは単に問題を移動します（BobのVMはスワップを開始します） 、およびa VMは、必然的に、ベアメタルよりもさらに遅くなります）。
現実の世界では、ジェフはおそらく正しいです-おそらくディスクIO制限ではなくRAM制限：ファイルの解凍は巨大ですディスクI/Oの量（圧縮ファイルから読み込み、CPUと少量のRAMを通過させ、非圧縮ファイルに吐き出します）。Nice（CPUの優先度に影響します）およびioniceがサポートされている場合（ディスクの優先度に影響を与えるため）、問題が軽減されます。
講義
何のためでもありませんが、オペレーティングシステムの設計教科書からこれと同じ質問を思い出します（例はgzip/gunzipではありませんでしたが）。現実の世界で実際にこの問題に遭遇する可能性はわずかですが、私には疑問があります。それは単に例を考えすぎているだけです。
覚えておいてくださいServer Fault is for system administrators and desktop support professionals, people who manage or maintain computers in a professional capacity-CS/301の宿題用ではありません。（ [〜＃〜] faq [〜＃〜] ）
これが実際の現実の問題である場合は、お詫び申し上げます。実稼働環境でこのコーナーケースに実際に遭遇したのは10000人に1人の可能性があります。