現行システム調査

=定期リリース作成時のdb03の負荷状況について=

リリース80作成時のdb03の稼働状況について確認した.

db03のハードウェア仕様は以下の通り. 現行システムの定期リリース処理はこのハードウェア上で処理を行っている.

定期リリース業務で計算機の処理時間がかかっているのは、以下の処理の模様.

12/4～12/6    GB_MER処理

12/18～12/22  MERG_STAT処理

12/18～12/21  MERG_DXM処理

この部分について、各種負荷状況について確認を行った.

CPU負荷分析
運用の中で採取されている、db03上のsarのログを加工してグラフ化した. 11/30～12/28までのCPUの負荷率でみると以下のようになっている. (12/7,12/15についてはsarログが存在しない為、その日の稼働状況は不明. )



12/18～12/22の間のCPU負荷が高いのがわかる. 特に12/12,12/19,20,21にCPU負荷率が高い時間帯があることがわかる.

プロセスアカウンティングログを確認して、CPU負荷の高い時間帯に起動され、終了しているプロセスの名前を確認すると、CPU利用率を上げているのは、

12/12 →ddbjff2xml_batch.plとgzipの実行の繰り返し

12/19,20,21→DXMLCheck_resizeの実行の繰り返し

の2つの処理であると思われる. （これらの処理は確認すると、INSD XMLファイルの作成とそのフォーマットチェックの処理）ただ、これらのプログラムは、その上位のシェルスクリプトから並行に実行するように呼ばれており、ある程度負荷状況を見込んで、意図的に負荷率を調整した上で呼ばれているようである. CPUが潤沢にあれば、並列度をさらに上げることができるとも考えられるが、周辺状況から、この処理が律速処理とも考えにくい.

メモリ負荷分析
メモリの使用状況については、以下のfreememのグラフを参照のこと.



物理メモリ搭載量は48GBと考えると、処理全体としてかなり余っていることになる. せっかく大型SMP機で動作させているのでもう少しメモリを有効に利用したほうがよいと考えられる.

IO負荷分析
ディスクの稼働状況についても確認した. 基本的にマウントされているRAIDパーティションの数個に対してアクセスが集中しており、特に、12/4から12/6の間の処理では１つのRAIDパーティション(3D+1P:RAID5)にアクセスが集中してしまっている.



ディスク1パーティションのbusy率が、長時間100％に張り付いてしまっている時間帯がある. 瞬間的にbusyとなることは通常の処理の中でも考えられるが、長時間連続してbusy率が100%に張り付くのは、この1ディスクパーティションに対するIO処理が律速処理になってしまっていると考えられる. また、その時のディスク上のファイルのメタデータへのアクセス状況を確認すると、大量のファイルを参照している様子が見える.



上グラフのigets,namei,dirbkは、それぞれSolarisの統計値で、

を表す.

カーネルパラメータで、inodeキャッシュがどれぐらいの大きさに設定されているかはわからないが、nameiはキャッシュに乗り切らないinode参照回数を表していると考えられ、大量のファイルのinode情報を頻繁にアクセスしている状況が見える. ディスクに対する大量のランダムアクセスが発生しており、これがdiskのbusy率を上げていることが推測される.

この結果を踏まえて当該時間帯に流れていたプログラムの処理をソースコードレベルで確認すると、フラットファイル内のエントリのソーティングの為に、フラットファイルを、1エントリ毎に、アクセッションIDをファイル名にしたファイルに分割して、それをlsでリストしてアクセッションIDのアルファベット順にソートしている処理があり、直接的にはこのプログラムの処理が律速処理になっていると考えられた.

まとめ
以上の稼働状況から


 * 定期リリース処理は、CPU、メモリ負荷と比べてディスクIOが重くかかる処理になっており、ディスクIOが主な律速処理になっている状況が推測できる.
 * 複数のディスクパーティションに負荷が分散されておらず、少数のディスクパーティションに負荷が集中しやすい処理になっている.
 * 現行処理では、1サーバでの大規模メモリは必要となっていない. (但し、ディスクIOとメモリ使用量はバーターの関係にあるので処理方法によって必要メモリ量が変わることは有り得る. ）

ことが言える.

以上のことから、ディスクにかかる負荷を分散させてやるか、あるいはメモリを有効に利用し、ディスクIOを軽減することができれば、現状長時間を要している定期リリース処理の処理時間を短縮することができると考えられる.