対策会議とCPU性能(2)

相変わらず日々対策会議に顔を出すのだが、メインスピーカーになりつつある中で考えが大分整理されて面白い。ちなみに面白いと思っては不謹慎な程事態は深刻であるが、技術的に上流を経験出来ると楽しみが増えるというのは本当かもしれない。

基本的な考え方の先には

面白いのはOS側の性能情報を見ているだけで、ユーザアプリケーションとデータベースの内部処理が多少透けて見えるようになる。

大規模な環境におけるインフラ観点のトラブルシューティング経験が生きている。おおよそのレベルでDBに要求されている処理の規模と、結果呼ばれているOSのリソース使用率から飽和状態に至らせているソフトウェア側の処理を想定できる。

これによってインフラ観点に論点を向けがちな開発側のマネージャーに対し、論点をソフトウェア側に誘導することで有効な切り分けの施策を提示することが出来る。

例えば、現在Turn Around Time(TAT:ソフトウェアの処理開始から終了までの時間）の処理種別ごとの合計かつ平均値を取って議論した結果、負荷が高い部分をCPU使用率とrqueueに限定して調査しているが、他の観点がごそっとぬけている。

おやおやソフトウェア側は何をもって問題ないとしているのか観点があいまいとなっている。これは、ソフトウェア側が切り分けの先導をしなければならないのだが、ボトルネックがサーバにあるだろうことを前提に議論されがちである。

おそらく開発したソフトウェアに手を入れる苦労が経験として明確にあるからであり、サーバサイドのチューニングや構成変更で大きく性能値が変わることで楽をしたいという（言えばずるい）考えがあるのだろう。これも透けて見える。

TATは性能評価の入り口としての指標

性能評価試験は、目標値としてTATが何秒以内、と定めたうえで実施する。比較はシステムリプレースの場合は現行システムの性能だし、新規システムの場合は要件とサンプルプログラムからの理想値を出す（んだと思う。ソフトウェア開発はしたことがないのでわからない）。

TATはソフトウェア処理開始から終了までの時間だが、当然その間様々なリソースによる処理が行われることになる。下記に流れを示すが、矢印を一巡するまでがこのTATという指標だ。

ソフトウェア処理
↓　↑
アプリケーションフレームワーク（ミドルウェア）
↓　↑
アプリケーションサーバ（OS）
↓　↑
【サーバハードウェア（APサーバ）】
↓　↑
ネットワーク（FW等含む）
↓　↑
【サーバハードウェア（DBサーバ）】
↓　↑
データベースサーバ（OS）
↓　↑
データベースミドルウェア（Oracle DBなど）
↓　↑
データベース（SQL性能）

ボトルネックを切り分けるにはこの流れにおいて、どの部分であるのかが焦点になる。大きく分けるならば、APサーバか、DBサーバかを見るべきだろう。

この切り分けは、サーバの性能情報データをまず見るのではない。まずはソフトウェアやアプリケーションフレームワークのログを解析し、DBサーバに処理を依頼し、APサーバに完了通知がされるまでのレスポンスタイムを計測しなければならない。

つまり、TATという処理全体の時間ではなく、DBサーバが処理をしていた時間を分析し、APサーバとDBサーバのいずれが時間を要していたかを解析する。

このとき、DBサーバとAPサーバの処理時間を単純比較してもいけない。DBサーバの処理時間が長いからと言って、そこにボトルネックがあるとは限らない。DBサーバの処理時間は、APサーバからの処理量によって変動するが、処理量（セッション数やデータ件数）を変動し数パターン計測し、どの程度の処理量で処理時間が著しく伸びるのかを判断しなければならない。

これを、スループットの飽和点を探ると私はよく表現するが、一体どこまでの処理にサーバ性能が耐えられるのかを明確にすることが優先事項だ。

サーバ資源は有限で、搭載しているCPU、メモリ、ディスクとそれらを結ぶ内部バスの性能によって、OSのカーネル処理が効率よく処理できる多重度の限界がある。このポイントがスループットの飽和点だ。

Linux OSの意外なボトルネック

また、一般的に想像できない飽和点として、/procの領域が挙げられる。Linux OSでは特にこの/procの処理がボトルネックになりがちである。/proc配下にはファイルが無数に存在するが、これらはデータとして実体をもたない。例えば/proc配下にPID（プロセスID）ごとのディレクトリが作成されるが、これはメモリ上に記録されているプロセス情報を参照している。

つまり、/procはカーネルがメモリの情報にアクセスするためのリンクファイルとして用いられている。

この領域が意外と罠であり、プロセスに straceなどを実行しシステムコールを読むと、/procを使用する頻度がかなり多いことが分かる。ソフトウェアの処理はおよそ多くても数種類をデータベースに対して要求するが、これらの処理の多重度を上げることは、内部的には同一のシステムコール群の多重度を上げることになる。

結果的に /proc 配下を参照するカーネル処理が多重度が比例して上がることになり、（リトライ処理などによって本来はさらに増えるのだが）特定のメモリ領域の参照処理が著しく増えた結果ボトルネック化する傾向を過去に経験している。

/proc配下は場合によっては排他制御されることもあるため、スレッドの待ち合わせが発生し、その場合はプロセスのCPU使用率が上がる。実際には「上がったように見える」なのであるが、これはCPUを占有している処理時間が伸びているわけではなく、Linuxの性能情報表示（topやvmstat等）のCPU使用率はアイドル時間からの引き算であるため致し方ない表現である。

という話を対策会議中にした、というのが昨日あった実際の話だ。偉い立場の皆さんが15名近く集まっていたが、「DBサーバのプロセスCPU使用率が高い」という言葉の呪縛からどうしても逃れられない様子であったための説明であったのだが、真の切り分けとしてはさらに上位から俯瞰した観点が必要ではないかと思っての本日の投稿である。

おそらくまだまだこの件は続くので、自分の整理のためにもまた書くかもしれない。