コンテキストスイッチ
論理CPU上で動作するプロセスが切り替わること
...
コンテキストスイッチは、プロセスがいかなるコードを実行中であろうとも、タイムスライスが切れると容赦なく発生します。
出典資料要約
ソースコードを書いて先にfoo()、直後にbar()という関数があるとする。foo()の後にタイムスライスが切れるとbar()は後回しになる。
つまりbar（）の処理完了に時間がかかった場合、bar()自身の問題だけでなくタイムスライスが切れて他のプロセスの処理をしているから時間がかかるという可能性がある。
ターンアラウンドタイムとスループットを見てみよう
システムを運用するにあたっては、システムに定められた性能要件を守る必要があります。
...
- ターンアラウンドタイム: システムに処理を依頼してから
個々の処理が終わるまでの時間 - スループット:
単位時間当たりに処理を終えらえる数
ターンアラウンドタイム（timeコマンドのrealの平均値
気づき
プロセス数が多くなると平均ターンアラウンドタイムが増加している
スループット（プロセス数/realの値）
気づき
プロセス数が多くなってもスループットが変わらない
結論
その後さらにプロセス数を増やしていくと、スケジューラが発生させるコンテキストスイッチが平均ターンアラウンドタイムを次第に長くするとともに、スループットを下げていきます。性能の観点で言えばCPUリソースを使って切っている状態でプロセスを増やせばいいというものではないのです。
ターンアラウンドタイム（webシステムについて）
論理CPUの負荷が高い状況でこのような処理を新たに到着すると、平均ターンアラウンドタイムがどんどん長くなっていきます。それはユーザから見ると、Webアプリケーションのレスポンス時間に直結するため、ユーザ体験が損なわれてしまします。応答性能重視のシステムは、スループット重視のシステムよりも、システムを構成する各マシンのCPU使用率を低めに抑える必要があります。
気づき
osとアプリケーションでCPUの使用率は大きく関係しているだなと改めて感じる
論理CPUの数を調べる
root@*********:************# grep -c processor /proc/cpuinfo
1
気づき
一個だけ
なんで今CPUの数を知るのか？
複数のCPU、複数のプロセスのターンアラウンドタイム
気づき
ターンアラウンドが少し変わった
複数のCPU、複数のプロセスのスループット
気づき
スループットが少し変わった
論理CPUが一個しかないからかな
参考書では4コアなので多分大きな変化があるのだと思う。
結論
論理CPUをたくさん積んでいるマシンがあったとしても、そこに十分な数のプロセスを実行させてはじめてスループットは向上する。
無闇にプロセス数を増やしてもスループットは向上しない
出典
感想
CPU数が多くてもスループットには限界がある。
プロセス数とCPU数が釣り合っているとスループットも良い
ターンアラウンドタイムは短くする工夫が必要だ
コンテキストスイッチで変わるんだな