回答:
「nice」のデフォルトの動作は、nicenessが変更された場合にもアプリケーションの「io」優先順位を調整することです。
もちろんすべてがワークロードに依存しますが、オペレーティングシステムの重要な側面の1つは、リソースの割り当て方法と競合の処理方法です。
競合するプロセスからの負荷がかかっている場合、オペレーティングシステムの動作が残りのワークロードに影響を与える可能性があるため、実際にナイスネスが何を行うかを理解することが重要です。
競合は、異なるアプリケーションが同じリソース（CPUなど）をめぐってどのように競合するかを示す尺度です。
負荷の処理
完全に公平なスケジューラが導入されて以来、niceは単に各プロセスの「ウェイト」句のフロントエンドにすぎません。これはプロシージャで表示できます。
$ cat /proc/self/sched
---------------------------------------------------------
...
se.load.weight : 1024
...
快適さを変えると、重みが変わるだけです。
$ nice -n 5 cat /proc/self/sched
---------------------------------------------------------
...
se.load.weight : 335
...
CPU競合の測定は、完全に公平なスケジューリングアルゴリズムによって行われます。すべてのアプリケーションには「ウェイト」値が割り当てられ、CPU時間の競合の場合、CPU時間を競合するすべての処理を合計し、それらのウェイト値に基づいて最も一般的なCPU時間を割り当てることで、プロセス間で時間が分割されます。
CPU時間をすべて使用したい3つのアプリケーションがある場合、デフォルトでは、通常の重みとして1024を受け取ります。上記のようにnice +5のプロセスが1つある場合、3つの重みすべてが2383で合計されます。つまり、3つのプロセスすべてがその秒のCPUを要求している場合、nicedプロセスは、1秒あたりのCPU時間の約15％を受け取ります。 。
CPUとIOの優先度を変える必要があるのはなぜですか？
ナイスネスは、システムに負荷がかかっているときに何をすべきか、つまり、オペレーティングシステムが必要なあらゆる要因によって定義された競合するプロセス間の時間をどのようにスライスするかを実際に操作するだけです。
これがユーザーにどのように影響するか、またはどのように関連するかは、さまざまなアプリケーションの配信優先順位と、各アプリケーションの配信にかかる時間によって決まります。
ナイスネスは、システムに負荷がかかっている場合にのみ何かを実行します（CPUまたはディスクが処理できるよりも多くの注意が必要なものがあります）。それらの状況下でリソースを割り当てる方法をカーネルに指示するだけです。
それらを異なるものにするための実際の使用法はありますか？
CPUで実行できるよりも多くの競合するプロセスまたは実行する作業がある場合、nicenessを使用すると、最初にどの作業が終了するかに関して比較的安定した保証が得られます。これは、別のレポートが完了する前に配信する必要があるレポートを作成する場合に重要になることがあります。
デスクトップシステムでは、快適さがさらに重要になります。特定のアプリケーションにはリアルタイムの動作があり、ロード中に頻繁にウェイクアップされるため、データが古くなるのを防ぎます。たとえば、Pulseaudioはこのカテゴリに分類されます。
他のアプリケーションは、依存アプリケーションの作業を分配するために必要になる場合があります。たとえば、MySQLのようなSQLサーバーがSQLが十分な速度でサービスを提供していないために、多くのApacheリクエストが長期間ブロックする可能性があります-他のレポートがCPU時間を競合していると言います。SQLが停止しているだけでなく、Apacheも停止しています。グループとして競合するApacheスレッドよりもワーカースレッドの方が通常ははるかに少ないため、SQLはここで害を及ぼす可能性があり、スケジューラーによってより適切に重み付けされ、SQLにより多くのCPU時間が与えられます。
UpdateDB（ファイルにインデックスを付けるプログラム）は夜遅く実行され、ディスクの負荷が非常に高くなります。IOスケジューリングの優先順位を下げて、その時点で他のアプリケーションが、順序でそれほど重要ではないものよりも優先されるようにすると便利な場合があります。
異なるCPUとIOの優先順位が必要な実世界のユースケースは何ですか？
ごくわずかです。素晴らしさは、ベストエフォート型のアプローチでは多すぎます。経験則として、私は、アプリケーションが実行して、どのようにうまくについてあまり気 より多くの彼らはどのようにひどく上の可能性が行います。これは最初は逆に聞こえるかもしれませんが、私には満たすためのサービス提供の保証があります。
「悪い日でもあなたの作品はXの期間で行われるだろう」と自信を持って言ってほしい。それが速くなる場合、それは単なるボーナスです。
私は通常、次のような合意された仕様を生成することから始めます。
そして、次のような条件を満たすための要件を引き出します。
仕様を提供することは真実であり、仮想化を行わずに、制御グループのはるかに効率的なアプローチを使用して、これらの目標を達成します。
コントロールグループを使用すると、指定された境界内でアプリケーションが動作する場合、リソース割り当てに対してかなり信頼できるサービスレベルを保証できます。これは、負荷がかかっているシステムでも、問題のアプリケーションのリソースの可用性を保証し、同じボックス上の他のアプリケーションのスペースを保証できることを意味します。
CPUとIOの例を見てみましょう。これらの要件を満たす制限を設定しました。
# cd /sys/fs/cgroup/blkio/apache
# echo "253:0 100" >blkio.throttle.read_iops_device
# echo "253:0 50" >blkio.throttle.write_iops_device
# echo "253:0 102400" >blkio.throttle.read_bps_device
つまり、100 iopsを読み取るには100kバイトです。
# cd /sys/fs/cgroup/cpu/apache
# echo 1000000 >cpu.cfs_period_us
# echo 60000 >cpu.cfs_quota_us
1秒の期間のうち、0.06秒のCPUを割り当てます。
# cd /sys/fs/cgroup/cpu/sql
# echo 1000000 >cpu.cfs_period_us
# echo 20000 >cpu.cfs_quota_us
1秒の期間のうち、0.02秒のCPUを割り当てます。
他の競合するcgroupを提供しても、何も馬鹿げたことはありません。各アプリケーションでCPUがどのように使用されるかを知っているので、負荷がかかっていることは私のサービス提供の要因にはなりません。
この性質のコントロールグループは、依然としてベストエフォートですが、ナイスネスやイオンネスよりもはるかに多くのコントロールを提供できます。