systemd サービスファイルでは、次のスケジューリング関連オプションを設定できます。systemd.execマニュアルページ、私が間違っている場合は訂正してください）：
いいね プロセス実行のデフォルトの良好レベル（スケジューリング優先順位）を設定します。 -20（最も高い優先順位）から19（最も低い優先順位）の整数を使用します。バラより優先順位の設定(2)もっと学ぶ。
かなりおなじみのレベルです。最近、Linuxカーネルの「自動グループ化」機能により、その効果がある程度「転倒」されたようです。したがって、以下のオプションは、おそらくデスクトップ環境でプロセスのパフォーマンスを維持するために本当に設定したいオプションです。
CPUスケジューリング戦略 実行プロセスの CPU スケジューリングポリシーを設定します。バッチ、アイドル、fifo、rrのいずれかを使用してください。バラよりsched_setscheduler(2)もっと学ぶ。
CPUスケジューリング優先順位 実行されたプロセスのCPUスケジューリング優先順位を設定します。使用可能な優先順位の範囲は、選択したCPUスケジューリングポリシーによって異なります（上記を参照）。リアルタイム予約ポリシーでは、1（最も低い優先順位）から99（最も高い優先順位）の整数を使用できます。バラよりsched_setscheduler(2)もっと学ぶ。
CPUSchedulingResetOnFork ブールパラメータを使用します。 true の場合、実行中のプロセスがフォークされたときに、上位 CPU スケジューリングの優先順位とポリシーがリセットされるため、子プロセスに漏洩しません。バラよりsched_setscheduler(2)もっと学ぶ。デフォルトは偽です。
最後のオプションを理解します。最初の2つの説明でスケジューリングポリシーを選択し、そのポリシーに基づいて優先順位を選択できることを知っています。どんな仕事のために何を選ぶべきかわかりません。たとえば、バックアップジョブに「アイドル」を選択するのは安全ですか（重複排除のために比較的多くのCPUを使用しています）、または他のジョブがより適切ですか？
全体的に私が探しているのは、各ポリシー、各優先順位、および特定の目的への適合性の理解しやすい概要です。美しいレベルとのやり取りも楽しいです。
CPUスケジューリングに加えて、IOスケジューリングもあります。ionice（間違っている場合は訂正してください）に該当するようです。
IOSスケジューリングクラス 実行されるプロセスのI / Oスケジューリングクラスを設定します。 0 から 3 の整数または none、realtime、best-effort、またはアイドル文字列のいずれかを使用します。バラよりioprio_set(2)もっと学ぶ。
IOSスケジューリングの優先順位 実行されたプロセスのI / Oスケジューリング優先順位を設定します。 0（最も高い優先順位）から7（最も低い優先順位）の整数を使用します。使用可能な優先順位は、選択したI / O予約クラスによって異なります（上記を参照）。バラよりioprio_set(2)もっと学ぶ。
ここでは、CPUスケジューリングと同じ構造を見ることができます。私も同じ種類の情報を探しています。
すべての「スケジューリング」オプションと同様に、参照されているマニュアルページは私にとって十分にはっきりしていません。
ベストアンサー1
CPUスケジューリング{ポリシー|優先順位}
CPUSchedulingPriorityこのリンクは、または（「ライブ」）ジョブに対してのみ設定する必要があることを示します。サービスのリアルタイム予約を強制したくありません。fiforr
CPUSchedulingPolicy=otherデフォルトです。
それからbatchとidle。これらの違いは、同時にCPUを消費する複数のアイドル優先タスクがある場合にのみ意味があります。理論的には、batch待ち時間が長くなるのではなく、より高いスループットを提供できます。しかし、これは大きな勝利ではないので、この場合は実際には関係ありません。
idle他のものがCPUを望むなら、飢えて死ぬでしょう。シングルコアを使用する以前のUNIXシステムでは、CPUの優先順位は以前ほど重要ではありません。nice私はそれに頼る前に良いレベル10または14から始める方が幸せですidle。次のセクションを参照してください。
しかし、ほとんどのデスクトップは、ほとんどの時間、比較的アイドル状態です。バックグラウンドジョブを先取りするCPUホグがある場合、そのホグは通常CPUの1つだけを使用します。これを念頭に置いて、idle通常のデスクトップやラップトップで使用することはそれほど危険ではないと思います。 Atom/Celeron/ARM CPUグレードがない場合約15ワット以下;では、もっと注意深く見てみたいです。
カーネル「自動グループ」機能はniceレベルを「アワビ」しますか？
はい。
自動グループ化がちょっと変ですね。著者はsystemdデスクトップでも経験的な方法が好きではありません。自動グループ化の無効化をテストするには、以下を設定できます。システム制御 kernel.sched_autogroup_enabled到着する0。私はsysctlを永続的な設定に設定して再起動して、すべての自動グループが削除されていることを確認してそれをテストするのが最善だと思いました。
これにより、問題なく良好なレベルのサービスを提供できます。少なくとも現在のバージョンのsystemdでは、次のセクションを参照してください。
たとえば、niceレベル10は、Linux CPUスケジューラの各スレッドの重みを約10％に減らします。良いレベル14は5％未満です。 （関連：完全なレシピ)
付録：niceレベルはsystemd cgroupによって「アワビ」されていますか？
現在のDefaultCPUAccounting= 環境サービス固有のCPU制御を有効にせずに有効にできない場合、デフォルトはオフです。だから大丈夫でしょう。現在の文書でこれを確認できます。man systemd-system.conf
サービス固有のCPU制御は、次の場合でも有効になります。どのサービスは、CPUAccounting/CPUWeight/StartupCPUWeight/CPUShares/StartupCPUShares を設定します。
次のブログの抜粋は古いですが、まだオンラインです。その後、デフォルトの動作が変更され、それに応じて参照文書も更新されました。
デフォルトでは、カーネルでCPUコントローラが有効になっていると、systemdは起動時に各サービスに対してcgroupを生成します。追加の設定なしですでに良い効果があります。 systemdシステムでは、すべてのシステムサービスは、含まれるプロセスの数に関係なく、同じ量のCPUを取得します。あるいは、言い換えれば：MySQLはWebサーバー上でApacheとほぼ同じ量のCPUを使用します。後者には1000のCGIスクリプトプロセスが含まれていますが、前者には少数のワーカージョブしか含まれていません。 （この動作はオフにできます。/etc/systemd/system.confのDefaultControllers =を参照してください。）
このデフォルト値に加えて、CPUShares =を使用してサービスから取得したCPU共有を明示的に構成できます。デフォルト値は 1024 です。この数を増やすと、変更されていない1024よりもサービスに多くのCPUが割り当てられ、この数を減らすとより少ないCPUが割り当てられます。