「Chrt」の版間の差分

提供:UnixClassWiki
ナビゲーションに移動 検索に移動
スケジュリングをスケジューリングに修正
40行目: 40行目:
マルチ・コアのCPUチップを使っているハードウェア環境でリアルタイムのSCHED_FIFOでプログラムを動かしている時、特定のプロセスをCPUコアに割り当てたまま、ずっと処理し続けるような条件になる時があります。
マルチ・コアのCPUチップを使っているハードウェア環境でリアルタイムのSCHED_FIFOでプログラムを動かしている時、特定のプロセスをCPUコアに割り当てたまま、ずっと処理し続けるような条件になる時があります。
他のプロセスは空いている他のCPUコアを使うので十分処理ができ、一方でSCHED_FIFOとして稼働中のプロセスが特定のCPUを占有してしまっているようなケースです。
他のプロセスは空いている他のCPUコアを使うので十分処理ができ、一方でSCHED_FIFOとして稼働中のプロセスが特定のCPUを占有してしまっているようなケースです。
このようなとき、システム的には問題がないのですが、(デフォルト)ではカーネルが1つのプロセスがCPUを占有していることに対して警告を出します。
このようなとき、システム的には問題がないのですが、デフォルトではカーネルが1つのプロセスがCPUを占有していることに対して警告を出します。


/var/log/messages に次のようなメッセージが大量に現れてシステム全体のパフォーマンスが落ちてしまう場合もあります。
/var/log/messages に次のようなメッセージが大量に現れてシステム全体のパフォーマンスが落ちてしまう場合もあります。

2018年11月9日 (金) 02:25時点における版

プロセスのスケジューリング種類を変更するコマンド

コマンド chrt は実行するコマンドもしくは実行中のプロセスのスケジューリングを変更するためのコマンドです。 プログラム中でシステムSCHED_SETSCHEDULERなどを使いスケジューリング種類や各種パラメータを変更することができますが、コマンドchrtはプログラム中でスケジューリングの種類を指定していなくても(プロセスのスケジューリングに関する処理を内部で行うことを必要とせず)外部からスケジューリングポリシーを変更することができます。

名前はchange real-time (.. attributes of a process ) の頭文字から来ていると思われますが、実際にはリアルタイムに関する各種パラメータだけではなくスケジューリングの種類そのものを変更することが出来ます。


次の例は chrt を使い コマンドps を SCHED_FIFO として実行しています。 psの出力をコマンド名、スケジューリング種類、リアルタイム・プライオリティ、(通常のプロセスの)プライオリティに指定したものです。つまり実行中のpsを自身で表示させたものです。 POL (Policy)はTSがTime Sharing、FFがFIFOの意味です。引数の99はリアルタイム・プライオリティを99に設定しています(最大値にしている)。 PRIは通常のプライオリティです。通常のコマンドの実行では20前後、コマンド類で優先的に実行したいものはおおよそ40前後程度ですが、ここにある139というのはカーネルの中でも最も優先度が高い値の1つになっています。


$ sudo chrt -f 99 ps -eo comm,policy,rtprio,pri
COMMAND         POL RTPRIO PRI
systemd         TS       -  19
...
migration/0     FF      99 139
watchdog/0      FF      99 139
...
sudo            TS       -  19
ps              FF      99 139

逆にこれがアイドル(SCHED_IDLE)にしたらどうなのでしょうか? ちなみにオプション -f ( SCHED_FIFO ) -r ( SCHE_RR ) 以外ではリアルタイム・プライオリティを0にしないとエラーになります。

% sudo chrt -i 0 ps -eo comm,policy,rtprio,pri
...
ps              IDL      0  19


soft lockup の警告

マルチ・コアのCPUチップを使っているハードウェア環境でリアルタイムのSCHED_FIFOでプログラムを動かしている時、特定のプロセスをCPUコアに割り当てたまま、ずっと処理し続けるような条件になる時があります。 他のプロセスは空いている他のCPUコアを使うので十分処理ができ、一方でSCHED_FIFOとして稼働中のプロセスが特定のCPUを占有してしまっているようなケースです。 このようなとき、システム的には問題がないのですが、デフォルトではカーネルが1つのプロセスがCPUを占有していることに対して警告を出します。

/var/log/messages に次のようなメッセージが大量に現れてシステム全体のパフォーマンスが落ちてしまう場合もあります。

% sudo grep 'soft lockup' /var/log/messages
... kernel: BUG: soft lockup - CPU#0 stuck for 10s! [myprog:3821]

これはカーネルがCONFIG_LOCKUP_DETECTORのオプションをつけたまま実行しているからです。 システム的に問題がないがなく、しかしながらsoft lockupのメッセージが大量に出てしまうためにトラブルになっている場合に限りますが、このオプションを切ってしまうことで少なくともシステムの警告はログファイルに出力されなくなります。 これは/boot/config-(カーネル番号)-xxx というカーネルのコンフィグレーションファイルの中にあるCONFIG_LOCKUP_DETECTORをオフすることで解決できます。 具体的な手順は書きませんが、このオプションをオフにしてカーネルのイメージを再構成すればメッセージは出なくなります。


プロセス管理 もしくは 目次