LinuCレベル4 システムアーキテクト 性能・拡張性の設計 問4
性能・拡張性の設計／性能の改善1台のサーバーで、応答時間が重視されるオンライン処理と、大量のCPUとディスクI/Oを使う集計バッチが同時に動いている。バッチの実行中はオンライン処理の応答が悪化する。追加のハードウェア投資はせず、バッチも止めずにオンライン処理を優先させたい。設計として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「性能・拡張性の設計」に対応。実際の試験問題ではありません）
- Acgroupでバッチとオンライン処理を別のグループに分け、バッチ側のCPUとI/Oの重みを小さくして配分を抑える
- Bオンライン処理のプロセスをリアルタイムスケジューリングのSCHED_FIFOに変更し、常にバッチより先に実行させる
- Ctunedでthroughput-performanceプロファイルを適用し、サーバー全体の処理能力を引き上げて両方の処理を速くする
- Dバッチのプロセスを起動する際のnice値だけを大きくし、I/Oを含むすべての資源でオンライン処理を優先させる
正解：A
解説
cgroup（v2）では、処理の種類ごとにグループを分け、cpu.weightやio.weightで資源の配分比率を、cpu.maxなどで上限を指定できます。バッチ側の重みを小さくすれば、競合時にはオンライン処理が優先され、オンライン処理が空いているときはバッチが余った資源を使えるため、バッチを止めずに応答時間を守れます。SCHED_FIFOは暴走時にほかのプロセスを実行させなくなる危険があり、業務処理の優先付けに使うのは一般に不適切です。niceはCPUのスケジューリング優先度を変えるもので、I/Oの帯域配分まで確実に制御するものではありません。
選択肢ごとの解説
- A正しい。グループ単位でCPUとI/Oの配分比率を指定できるため、競合時にだけオンライン処理を優先させ、空き資源はバッチが使えます。
- B誤り。リアルタイムスケジューリングのプロセスが処理を続けるとほかのプロセスが実行されなくなる恐れがあり、業務処理の優先付けには危険です。
- C誤り。プロファイルはシステム全体の傾向を調整するもので、処理ごとの優先度を付けないため、バッチによる資源の奪い合いは解消しません。
- D誤り。nice値はCPUの配分に作用します。I/O優先度を明示しない場合はnice値から導かれますが、それが効くのはBFQなど優先度を扱うI/Oスケジューラを使うときだけで、mq-deadlineやnoneでは配分に反映されないため、I/Oの競合による応答悪化は残り得ます。