処理の実行
- サーバのCPU使用率
- CPUの速度とAPPの処理速度
プロセスとスレッド
プロセスとは、プログラム（実行バイナリ）が OS上に実体を持ち、実行できる状態になったもののこと。
プロセスはプログラムがメモリにロードされて実行できる状況になったものを指す。
スレッドは、プロセスの中での実行単位。
たいていのDBMSは並列処理が可能なので、プロセスかスレッドのどちらかを複数にすることで同時に複数の処理ができるようになっている。
約80個のプロセスで testdbという Oracle Databaseを構成している。
1つのプロセスで実行されている MySQL。
スレッドまで見えるオプション（-m）をつけると、mysqldが複数のスレッドで構成されている
約7個のプロセスで PostgreSQLは構成されている模様。
プロセス数やスレッド数の上限
大規模システムでもない限り、プロセスやスレッドの数に関するOS側の上限（設定可能な最大値）は問題にならない。それよりも、消費されるメモリ量や DBMSの性能が問題視される傾向にある。プロセスやスレッドの数が増えると、それに応じてメモリを割り当てる必要があるため、メモリの消費量が増える。DBMSのプロセス数（もしくはスレッド数）が増えると、内部競合やコストが増加するため、レスポンスタイム（DBMSへ処理を依頼してから最初の結果が返ってくるまでの時間）は下図のような曲線を描くとされる。
このような曲線を描く理由としては、プロセスがある処理をする際に、他のウロセス全ての情報をチェックしたり、管理情報へのアクセスで強豪が起きたりするなど、処理のオーバヘッドが増えることが挙げられる。
この曲線の上がり方が極めてゆるい＝「スケーラブル（拡張性が高い）」と表現される。スケーラブルといっても、多すぎるとトラブルになることもあるし、データベースの設計やアプリケーションの設計が悪いと、データベースへのアクセスでボトルネックが発生し、プロセスやスレッドの数を増やしても性能が上がらなくなることがあるから注意が必要。
プロセスの生成から処理の実行まで
- 「生成」はプロセスの誕生
- 「実行可能」は準備が整った状態
- 「実行」はCPUが使用できるようになった状態になり、処理が行われる
- 「スリープ」は待ちの状態、読み書きなどで自分から処理を止めたり、システム利用者やネットワークからの入力待ちなどもある
プロセスの状態とCPU使用率の関係
- 1つのプロセスの状態が実行中（O）の場合は、1つのCPU（コア）がCPU使用中となる。
- 実行可能な状態（R）の場合は、CPUの使用率に現れず、run queueにでてくる。
- I/O待ちの場合は2つに分かれる
- 通常のディスクI/O：wait I/OとしてCPU使用率に現れる場合がある（vmstatなどでは b列（ブロックされているプロセス／スレッド数）に出る）
- ネットワークのI/O：基本的に wait I/Oには含まれない
- プロセス全てがスリープ状態であれば、CPUはアイドル（idle）
CPU使用率の内訳
- CPUの使用率の３つの状態
- SYS（sy）：カーネルが使用した時間の割合（ユーザアプリケーションがOSを呼び出す際にカーネル内部で発生する処理はこちら）
- USER（us）：ユーザが使用した時間の割合
- IDLE（id）：CPU上で処理されているものがないことをさす
CPU使用率
使用率というのは処理中を表し、待ちの計算は指数分布で求めている。理想的な動きをした場合の結果を示す
DBMSのCPU待ち行列はどうか
1CPUのマシンで、バッチ処理を多重化せずに実行したとする。しかも、それが集計処理など非常に時間のかかるSQLで、I/Oのほとんどない処理だとすると、処理の間CPUを占有していても珍しくない。この場合、CPU使用率が高いのに待ちが少ない状況が起きる。
システム方針次第で状況はよくもあり悪くもある
- バッチ処理でのCPU使用率100%は、早く処理するためにリソースを使い切っているから望ましい状態、遅くなっていないからOK
- バッチ処理の時間中にオンライン処理が入った場合、オンライン処理が遅くなる可能性を考えると、CPUを100%使い切るのは良くない
バッチ処理でDBMSがCPUを効果的に使い切る
CPUが1つのマシンで、バッチ処理を多重浮かせずに実行する。非常に時間のかかるSQLで、I/Oが発生する。
処理の半分がI/O待ちだとすると、CPU使用率は50%
- I/O待ちがなくなるようにチューニング
- DBMSのキャッシュサイズを大きくして、2回目以降のデータアクセスを早くする
- 多重処理ができるようにバッチを組む
バッチ処理では処理ぜないが終わる時間が問題で、個々のSQL文の実行が終わる時間（レスポンス時間）は問題にならないはず。処理をいっせいに投入して待ち行列ができるパターンと、CPU使用率が100%にならないように工夫して投入したパターン
SQLのレスポンスタイムはことなるものの、いっせいに投入しようがしまいが、全体で使用するCPU時間は変わらない。
