コンテキストスイッチ
Context Switch
CPUが現在実行中のプロセスやスレッドの状態を保存し、次に実行するプロセスやスレッドの状態を読み込んで処理を切り替えること。
🐾 猫で例えると?
先ほどまで激しく殴り合いの喧嘩を繰り広げていたはずのアメショと茶トラが、次の瞬間にはお互いに組み合ったまま嘘のように爆睡していることがあります。限界まで高まっていた「戦闘」状態の記憶をパッと脳の奥に保存し、即座に「睡眠」モードのコンテキスト(状態情報)を読み込んで処理を切り替えたかのようです。システムにおけるコンテキストスイッチも、これと同じように実行中のタスクを一時中断して、別のタスクへと超高速で切り替える制御を行っています。
🐾 猫あるある:IT現場の日常
- 寝ていたはずが、物音一つで戦闘モード:待機中プロセスが割り込み信号を受信し即座に実行状態へ移行
- 甘えていた直後に、急に冷たくなって去る:ユーザー入力処理が完了し、アイドルプロセスへ制御が移る状態
- 食べている最中に、虫に意識が完全に飛ぶ:優先度の高い割り込み処理が発生し、現在のタスクが中断される状態
💻 システム開発における「コンテキストスイッチ」とは?
コンピュータが複数のプログラムを同時に実行しているように見えるのは、このコンテキストスイッチのおかげです。CPUは実際には1つのプログラムしか同時に処理できませんが、超高速でコンテキストスイッチを繰り返すことで、ユーザーにはあたかも複数のプログラムが同時に動いているように錯覚させます。
具体的には、CPUは現在実行中のプログラムのレジスタやスタックといった「コンテキスト(状態情報)」をメモリ(またはPCB:プロセス制御ブロック)に保存します。そして、次に実行するプログラムの保存されていたコンテキストを読み込み、CPUの各レジスタに再セットします。この一連の作業がコンテキストスイッチです。
⚠️ コンテキストスイッチの仕組みとオーバーヘッド
コンテキストスイッチはOSのカーネルによって制御されます。割り込み(I/O要求やタイマーなど)やシステムコールがトリガーとなります。しかし、この切り替え作業自体がCPUリソースを消費するため、「コンテキストスイッチのオーバーヘッド」と呼ばれるパフォーマンス低下の要因になります。
コンテキストスイッチの頻度と影響
あまりにも頻繁にコンテキストスイッチが発生すると、CPUはプログラムの実行よりも切り替え作業(状態の保存と読み込み)ばかりに時間を取られてしまい、システム全体の処理能力が著しく低下します。これを防ぐために、OSはスケジューリングアルゴリズムを駆使して、最適なタイミングで切り替えを行います。
// Linuxでのコンテキストスイッチ数の確認(vmstatコマンド)
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 1234567 890123 456789 0 0 1 5 10 50 10 5 85 0 0
2 0 0 1234000 890123 456789 0 0 0 0 100 500 20 10 70 0 0
...
// 'cs'列が1秒間に発生したコンテキストスイッチ数。
// 'in'列は1秒間に発生した割り込み数。 上記のvmstatコマンドの実行結果において、`cs`(Context Switch)の数値が異常に高い場合は、システムがタスクの切り替え処理に追われ、本来のアプリケーション処理にリソースを割けていない可能性があります。
🛠️ コンテキストスイッチを賢く使うためのポイント
アプリケーション開発やインフラ構築において、不要なコンテキストスイッチを減らすことはパフォーマンスチューニングの鉄則です。
- 適切なスレッド数の設計: CPUコア数に対して過剰なスレッドを生成すると、切り替えによるオーバーヘッドが急増します。
- 非同期I/Oの活用: I/O待ちによるスレッドのブロックと切り替えを防ぐため、Node.jsなどの非同期イベント駆動モデルが有効です。
- プロセスの多重度最適化: Webサーバー(ApacheやNginxなど)の同時接続数やプロセス割り当てをハードウェア性能に合わせて調整します。
激しい喧嘩の途中で急に電池が切れたように眠ってしまう猫たちのように、システムも時には無駄なプロセスを眠らせ、効率よくリソースを切り替えることが重要です。システムの動きが重いと感じたときは、タスクの切り替え頻度やプロセス数を見直してみましょう。