第10章　プロセス優先度とジョブ制御の応用

LPIC-1 103.5 / 103.6 相当

初級の第7章ではプロセスの基本操作を扱いました。ここでは、複数のプロセスが同時に動くときの「優先度」の考え方を学びます。

優先度（nice値）とは

Linuxのプロセスには nice値 という、CPUをどれだけ譲るかを示す数値があります。範囲は -20（最優先）〜19（最も譲る）で、既定値は0です。名前のとおり、値が大きいほど他のプロセスに「優しく（nice）」なります。

なぜこの仕組みが必要かというと、CPUは同時に1つのプロセスしか処理できない（マルチコアでもコア数分しか同時に処理できない）ため、カーネルのスケジューラは「どのプロセスに次のCPU時間を割り当てるか」を常に判断しています。nice値はこの判断材料の一つで、値が低い（マイナス側）プロセスほど優先的にCPU時間を割り当ててもらいやすくなります。バッチ処理やバックアップのような、多少遅くても構わないが他の対話的な処理の邪魔をしたくない作業には、nice値を上げて優先度を下げておくのが定石です。

nice — 優先度を指定して起動する

$ nice -n 10 ./heavy-task.sh    # nice値10で起動（優先度を下げる。プロセス自体の出力以外は表示なし）
$ sudo nice -n -5 ./important.sh # 優先度を上げるにはroot権限が必要（同様に無出力）
$ nice                          # 引数なしで実行すると、現在のシェルのnice値（既定0）を表示
0

一般ユーザーは自分のプロセスのnice値を「上げる」（優先度を下げる）ことはできますが、一度上げた値を元に戻したり、マイナス値にして優先度を上げたりするにはroot権限が必要です。これは、一般ユーザーが自分のプロセスの優先度を勝手に最優先にしてシステム全体を占有してしまうのを防ぐための制限です。

renice — 実行中のプロセスの優先度を変更する

$ renice 5 -p 1523      # PID 1523のnice値を5に変更
1523 (process ID) old priority 0, new priority 5
$ renice -n 5 -p 1523   # -n を付ける書式もある（意味は同じ）
1523 (process ID) old priority 5, new priority 5
$ renice 10 -u alice    # -u でユーザー単位（aliceの全プロセス）に変更することも可能
1000 (user ID) old priority 0, new priority 10

この行のこの値に注目： reniceは変更対象ごとにold priority ... new priority ...という形式で変更前後のnice値を報告します。-u aliceの場合は個々のPIDではなくユーザーID単位でまとめて報告される点が、PID指定の場合との違いです。

uptime とロードアベレージ

uptime はシステムの稼働時間に加えて、ロードアベレージ（load average）という、CPUの実行待ちが発生しているプロセス数の平均を表示します。

$ uptime
 10:32:01 up 5 days,  3:11,  2 users,  load average: 0.15, 0.22, 0.30

3つの数値は、それぞれ直近1分・5分・15分の平均です。この値がCPUのコア数を大きく上回っている状態が続く場合、システムに負荷がかかりすぎている可能性があります。例えば4コアのサーバーでロードアベレージが8.0で高止まりしているなら、常にCPUの空きを待っているプロセスが存在することを意味し、処理の遅延や応答性の低下につながります。逆に1分値だけが一時的に跳ね上がっていて5分・15分値が低い場合は、瞬間的な負荷の可能性が高く、傾向を掴むには3つの数値の推移を見比べることが大切です。

ps のオプションの違い

ps aux の出力にはいくつも列がありますが、代表的なものだけでも意味を押さえておくと障害調査の際に役立ちます。

$ ps aux | head -3
USER   PID  %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     1   0.0  0.1 168000 11000 ?        Ss   Aug10   0:03 /sbin/init
alice  4821   0.2  0.3  22000  8000 pts/0    S    10:30   0:00 sleep 300

STATがZ（ゾンビ）のプロセスは、処理自体はすでに終了しているものの、親プロセスが終了ステータスを回収（wait）していないために一覧に残り続けているものです。ゾンビプロセス自体はリソースをほとんど消費しませんが、大量に発生している場合は親プロセスの実装に問題がある可能性があります。

topコマンドによるリアルタイム監視

psがその瞬間のスナップショットを表示するのに対し、topは一定間隔で情報を更新し続け、CPUやメモリを多く使っているプロセスを一目で把握できます。

$ top
top - 10:32:01 up 5 days,  3:11,  2 users,  load average: 0.15, 0.22, 0.30
Tasks: 120 total,   1 running, 119 sleeping
%Cpu(s):  3.2 us,  1.1 sy,  0.0 ni, 95.5 id
PID   USER  PR  NI  %CPU  %MEM  COMMAND
4821  alice  20   0   0.2   0.3  sleep

top実行中に押せるキーにもよく使うものがあります。kでPIDを指定してシグナルを送信、rでreniceと同様に優先度を変更、qで終了です。より高機能な派生版としてhtopもよく使われます。

ジョブ制御 — フォアグラウンドとバックグラウンド

時間のかかる処理は、バックグラウンドで実行しつつ他の作業を続けることができます。

$ sleep 300 &
[1] 4821
$ jobs
[1]+  Running    sleep 300 &
$ fg %1     # フォアグラウンドに戻す（Ctrl+Cで中断可能になる）
sleep 300

この行のこの値に注目： fgを実行すると、その時点でフォアグラウンドに戻すコマンドライン自体（sleep 300）がまずエコー表示され、その後は処理が終わるかCtrl+C/Ctrl+Zを押すまでプロンプトに戻りません。

Ctrl+Zで止めた直後のジョブは「停止中（Stopped）」の状態で、CPUを消費していません。bg %1でバックグラウンドに回すと、止まっていた処理が再開してバックグラウンドで動き続けます。jobsの出力にある+は「直前に操作したジョブ（カレントジョブ）」、-は「その一つ前のジョブ」を表す記号で、%+や%-でもそれぞれを指定できます。

nohup と disown — ログアウト後もジョブを続ける

通常、端末を閉じたりSSH接続が切れたりすると、そのシェルが管理していたジョブにはSIGHUPシグナルが送られ、処理も一緒に終了してしまいます。長時間かかる処理をログアウト後も続けたい場合には、次のような方法があります。

$ nohup ./long-task.sh &
[1] 5012
$ disown %1     # 既に起動済みのジョブ番号1をシェルの管理対象から外す（正常時は無出力）

シグナルの送信

プロセスへ終了などの要求を伝える手段が「シグナル」です。killコマンドは名前に反して、実際には指定したシグナルをプロセスに送るコマンドです。

$ kill 4821            # SIGTERM（既定）を送信し、正常終了を要求（正常時は無出力）
$ kill -9 4821         # SIGKILLで強制終了（正常時は無出力）
$ kill -l               # 利用可能なシグナルの一覧と番号を表示
 1) SIGHUP	 2) SIGINT	 3) SIGQUIT	 4) SIGILL	 5) SIGTRAP
 6) SIGABRT	 7) SIGBUS	 8) SIGFPE	 9) SIGKILL	10) SIGUSR1
...（この後もシグナル一覧が続く）
15) SIGTERM
$ killall nginx        # プロセス名を指定して一括送信（正常時は無出力）
$ pkill -u alice        # 特定ユーザーが所有する全プロセスへ送信（正常時は無出力）

この行のこの値に注目： kill -lの一覧番号は、表内で紹介したSIGKILL（9）やSIGTERM（15）と一致しており、kill -9のように番号でシグナルを指定する際にこの一覧で正確な番号を確認できます。kill・killall・pkillはいずれも、対象が見つかって正常にシグナルを送れた場合は何も表示しません。

I/Oスケジューリングクラス（ionice）

nice/reniceがCPU時間の優先度を扱うのに対し、ディスクの読み書き（I/O）の優先度を調整したい場合はioniceコマンドを使います。バックアップ処理のように大量のディスクI/Oを発生させる作業を、他のサービスの応答性を落とさずにバックグラウンドで実行したい場合に有効です。

$ ionice -c 3 -p 4821       # PID 4821のI/O優先度をIdle（他に処理がないときだけ実行）に設定
$ ionice -c 2 -n 7 rsync -a /data /backup   # Best Effortクラスの最低優先度でrsyncを起動

CPU負荷は低いのにサーバー全体が重い、という場合はCPUではなくディスクI/Oがボトルネックになっている可能性があり、ioniceや後述のiostatのようなI/O関連のツールを確認する視点も持っておくと、原因の切り分けの幅が広がります。

プロセスの優先度とコンテナ環境

近年ではDockerなどのコンテナ上でアプリケーションを動かすことも一般的になっていますが、本章で扱ったnice/ioniceの考え方は、コンテナ環境でも形を変えて生きています。Dockerの--cpu-sharesや--memoryのようなオプションは、複数のコンテナが同じホストのリソースを取り合う際の割り当て比率を指定するもので、根本的な発想はLinuxのプロセス優先度制御（cgroupsという仕組みを土台にしています）と共通しています。ホストOS上での優先度制御の考え方を理解しておくと、コンテナ技術を学ぶ際にも応用が利きます。