デスクトップコンテキストでのsystemdスケジューリング関連オプションの使用と理解

systemdサービスファイルでは、次のスケジュール関連オプションを設定できます（systemd.execmanページから、間違っている場合は修正してください）。

Nice 実行されたプロセスのデフォルトのniceレベル（スケジューリング優先度）を設定します。-20（最高の優先度）から19（最低の優先度）の間の整数を取ります。詳細については、setpriority（2）を参照してください。

おなじみのいいレベルです。最近のLinuxカーネルの「オートグループ」機能により、その効果はいくぶん「覆された」ようです。したがって、以下のオプションは、デスクトップエクスペリエンスでプロセスが適切に動作し続けるように設定したいものです。

CPUSchedulingPolicy 実行されたプロセスのCPUスケジューリングポリシーを設定します。その他、バッチ、アイドル、FIFO、またはRRのいずれかを取ります。詳細については、sched_setscheduler（2）を参照してください。

CPUSchedulingPriority 実行されたプロセスのCPUスケジューリング優先順位を設定します。使用可能な優先度の範囲は、選択したCPUスケジューリングポリシーによって異なります（上記を参照）。リアルタイムスケジューリングポリシーでは、1（最低の優先度）から99（最高の優先度）までの整数を使用できます。詳細については、sched_setscheduler（2）を参照してください。

CPUSchedulingResetOnFork ブール引数を取ります。trueの場合、実行されたプロセスがフォークすると、CPUスケジューリングの優先順位とポリシーの昇格がリセットされるため、子プロセスにリークすることはできません。詳細については、sched_setscheduler（2）を参照してください。デフォルトはfalseです。

最後のオプションを理解しました。最初の2つの説明から、スケジューリングポリシーを選択し、そのポリシーを優先することができると説明しました。どの種類のタスクのために何を選択すべきかは、私には完全に明確ではありません。たとえば、バックアップタスクに「アイドル」を選択しても安全ですか（重複排除のために比較的CPUに負荷がかかります）、それとも別の方が適していますか？

一般に、各ポリシーの概要と、その優先順位と特定の目的への適合性を理解することは、私が探しているものです。niceレベルとの相互作用も興味深いものです。

CPUスケジューリングの次に、IOスケジューリングがあります。これはionice（間違っている場合は修正してください）に相当すると思います。

IOSchedulingClass 実行されたプロセスのI / Oスケジューリングクラスを設定します。0〜3の整数、またはnone、realtime、best-effort、idleのいずれかの文字列を取ります。詳細については、ioprio_set（2）を参照してください。

IOSchedulingPriority 実行されたプロセスのI / Oスケジューリング優先順位を設定します。0（最高の優先順位）から7（最低の優先順位）までの整数を取ります。使用可能な優先度は、選択したI / Oスケジューリングクラスによって異なります（上記を参照）。詳細については、ioprio_set（2）を参照してください。

ここでは、CPUスケジューリングと同じ構造が表示されます。同じ種類の情報も探しています。

すべての「スケジューリング」オプションについて、参照されたマニュアルページは私にとっては十分に明確ではありません。ほとんどは、技術的にやや傾けられたデスクトップユーザーの視点に物事を翻訳することにおいてです。

CPUScheduling {Policy | Priority}

リンクはCPUSchedulingPriority、fifoまたはrr（「リアルタイム」）タスクに対してのみ設定する必要があることを示しています。サービスにリアルタイムのスケジューリングを強制したくない場合。

CPUSchedulingPolicy=other デフォルトです。

その葉batchとidle。それらの違いは、同時にCPUを消費するアイドル優先度のタスクが複数ある場合にのみ関係します。理論的にbatchは、より長いスループットと引き換えに、より高いスループットが得られます。しかし、それは大きな勝利ではないので、この場合はあまり関係ありません。

idle他にCPUが必要な場合、文字通り飢餓状態になります。単一コアの古いUNIXシステムでは、CPU優先度は以前よりも重要度が低くなっています。私はniceに頼る前に、例えば素敵なレベル10または14 から始めてもっと幸せになるでしょうidle。次のセクションを参照してください。

ただし、ほとんどのデスクトップはほとんどの場合比較的アイドル状態です。また、バックグラウンドタスクをプリエンプトするCPUホグがある場合、ホグはいずれかのCPUのみを使用するのが一般的です。それを念頭に置いて、私はidle平均的なデスクトップまたはラップトップのコンテキストで使用することはあまり危険を感じません。約15ワット以下の定格のAtom / Celeron / ARM CPUがない場合。それからもう少し注意深く見たいと思います。

カーネルの「自動グループ」機能によって、適切なレベルが「破壊」されていますか？

うん。

自動グループ化は少し奇妙です。の作者はsystemd、デスクトップであってもヒューリスティックを好まなかった。自動グループ化の無効化をテストする場合は、sysctl kernel.sched_autogroup_enabledをに設定できます0。sysctlを永続的な構成に設定して再起動し、すべての自動グループを削除することを確認してテストするのが最善だと思います。

そうすれば、問題なくサービスのレベルを上げることができるはずです。少なくとも現在のバージョンのsystemd-次のセクションを参照してください。

たとえばniceレベル10は、Linux CPUスケジューラでの各スレッドの重みを約10％に減らします。ナイスレベル14は5％未満です。（リンク：完全な式）

付録：systemd cgroupsによって素敵なレベルが「破壊」されていますか？

サービスごとにCPU制御を有効にせずに有効にできない限り、現在のDefaultCPUAccounting= 設定はデフォルトでオフになっています。だから大丈夫です。これは、現在のドキュメントで確認できます。man systemd-system.conf

サービスごとのCPU制御は、サービスがCPUAccounting / CPUWeight / StartupCPUWeight / CPUShares / StartupCPUSharesを設定した場合にも有効になることに注意してください。

次のブログの抜粋は古くなっています（まだオンラインです）。その後、デフォルトの動作が変更され、それに応じてリファレンスドキュメントが更新されました。

適切なデフォルトとして、カーネルでcpuコントローラーが有効になっている場合、systemdは起動時に各サービスのcgroupを作成します。これ以上の設定がない場合、これにはすでに1つの素晴らしい効果があります。systemdシステムでは、構成されているプロセスの数に関係なく、すべてのシステムサービスが均等な量のCPUを取得します。または言い換えると、Webサーバーでは、MySQLはApacheとほぼ同じ量のCPUを取得します。後者は、1000のCGIスクリプトプロセスで構成されていますが、前者はいくつかのワーカータスクのみです。（この動作はオフにすることができます。/etc/systemd/system.confのDefaultControllers =を参照してください。）

このデフォルトに加えて、サービスが取得するCPUシェアをCPUShares =設定で明示的に構成することが可能です。デフォルト値は1024です。この数を増やすと、変更されていない1024よりも多くのCPUがサービスに割り当てられ、減らすと少なくなります。

http://0pointer.de/blog/projects/resources.html

古典的なパフォーマンスチューニングのアドバイスは、「最適化しない、ベンチマーク」です。

一般的なアドバイスを気にするのではなく、改善が懸念され、特定のパフォーマンスの懸念があるとベンチマークされている特定のケースから始めます。データを調整するための適切なディレクティブに進みましょう。データを使用すると、プロセスの優先度が低いか、CPUを占有しているか、または別の問題があるかが明らかです。

最近のデスクトップは、まったく調整しなくても十分に高速で動作することがよくあります。