対策会議とCPU使用率

連日、システム性能試験が上手くいかず、対策会議に出席している。

何を対策しているかというと、開発されたソフトウェアの性能目標値を達成するようサーバのチューニングをするのだが、これがかなり勉強になる。

技術的にも勉強になるのだが、なにやらOS側の筆頭担当者となってしまったので、プロジェクト途中参加ではあるが、一気に他社上層部と距離を詰められているので、マネージャーとしの勉強にもなるため良かったかなと思っている。

焦点はソフトウェアのTAT（Turn Around Time: 処理の開始から終了まで）という時間だ。システムが提供するサービスの0ソフトウェアが処理をデータベースに要求するのだが、データベースが稼働するサーバCPU使用率にも問題がありそうだ。

CPU使用率というと、直感的にどれくらいCPUが稼働していたか、を想像するが性能情報を調査するコマンドによってはあいまいな数値が出ることがある。

linux OSならtopコマンドやvmstatコマンドなどを多く利用するが、CPU使用率として表示される値は実際にはCPUが使われた時間帯ではないそうだ。

例えばCPU単位に50%の使用率だった、などと表現するが、これはCPUがフル稼働した状態100％からCPUがアイドル状態であったCPU時間を差し引いた値である。

なんのこっちゃである。

ここからは技術論。

たとえCPUが演算を行っていなかったとしても、CPU自体のアイドル状態が発生していなかったならば、何かしらCPUを使っていただろうという逆説的な値を指標として参照していることになる。

また、サーバのプロセス単位でもCPU使用率を捉える。プロセスがCPUを利用する単位をスレッドと言い、複数のスレッドでプロセスは構成される。

サーバでは複数のスレッドが動くことになるが、それらの数に対してCPUのコア数は一般的に少ない。少ないCPUでサーバが要求する全ての命令を処理するには、複数スレッドを交代でCPUを使わせる仕組みがいる。

その処理をコンテキストスイッチと呼び、そのタイミングでCPUのアイドル時間を追跡するらしい。

プロセスの処理ではメモリ上の情報を読み込むが、大量のスレッドがメモリ情報にアクセスすると、情報によっては排他制御がかかる場合もあり、待ちが発生する。

何が起きるかと言うと、一見CPU使用率が高かったプロセスは実際にはCPU演算を行なっておらず、待っていたにも関わらず、コンテキストスイッチのタイミングでアイドル状態でなかかったと言う理由でCPU時間が高いと言う指標を出されてしまう。

そんな処理に踊らされた我々は、CPU使用率が高かったプロセスの動作を止めても、性能全然かわんないじゃんと言う結果をお見舞いされたのであった。

切り分けなので良いのだが、なかなか勉強になる。

まだまだ続くので何かトピックがあればアウトプットしたい