消えたパフォーマンス―ボトルネックを探せ!

EnterpriseZine / 2014年1月8日 9時0分

▲[T_Order_Idx1] がステータス列 (OrderStatsu列) のインデックス。T_Order_Idx1 のスキャン (Index Seek) で0のデータを取得し、Nested Loopsの外側のループはその件数分ループする。内側のループはKey検索になるので外側のループ1回につき1回実行される(つまり、内側はループというよりただのキー検索)。なお、このような単純なクエリだと、ステータス列にインデックスを作成しただけでは使用されなかったのでヒント文を付けています。

 どのような経緯だったのかはすっかり忘れてしまったのですが、あるお客様がSQL Server 2000で思ったほどパフォーマンスが出ないので調査してほしいという話が私のところに来ました。詳しく話を聞いてみると…

●案件の概要

 そのお客様のアプリケーションというのは、もともとオラクルを使用していたものを、いろいろと理由があってSQL Serverを使用するよう変えたという事でした。期待したほどパフォーマンスがでないので、オラクルに戻すか、SQL Server 2005にアップグレードするかを検討中でしたが、パフォーマンス問題の原因が判明していない状況でSQL Server 2005にアップグレードするのは考えられないという状況だったのです。

■なぜ、パフォーマンスが出ない?

 お客様のシステムに関する資料をいくつかいただきましたが、それだけでは不明な点も多かったので、お客様の所へお伺いしてヒアリングすることになりました。お客様のシステムというのは次のようなものです。

 まず、注文データがSQL Serverのデータベースに随時登録されます。この注文データを登録するアプリケーションについては、現時点で特に問題になっていません。

 次に、バッチジョブが登録されたデータを加工して、さらに別のシステムへ転送します。注文データは日々大量に登録されるため、データを加工して転送するアプリケーションはできるだけ早く転送できるよう複数のサーバーで稼働していました。パフォーマンスが期待したほど出ないのは、この転送アプリケーションなのだそうです。アプリケーションサーバーのCPUリソースは十分に空きがあるので、SQL Server側が遅延しているようだということです。

 ここまでの話を聞いて、私はお客様へ「オラクルからSQL Serverへ移行するときに、このアプリケーションを何か変更しましたか?」と尋ねました。この質問に対するお客様の回答は「SQL Serverで動作するよう最小限の変更はあったが、基本的にはクエリやアプリケーションも何も手を加えていない。」というものでした。

 私はアプリケーションの動作を詳細に確認したくなったので、お客様にアプリケーションを貸してもらえないか打診してみました。話を聞く限り、システムは比較的シンプルな仕組みですし、貸与いただけるのであれば私の手元で動作させることができるのではないかと考えたのです。

 わざわざアプリケーションを借りなくても、本番環境やテスト環境で情報採取して確認することはできますが、お客様としてはあまり本番環境に触れてほしくないという思いがあったのと、私自身も問題が特定できた後にそれがSQL Server 2005にアップグレードすることで解消されることを一気に証明したかったのです。また、お客様のテスト環境ではSQL Server側のボトルネックが検出できていないというのも理由の一つでした。

 このような考えを一通り説明したところ、お客様からアプリケーションをお借りすることができました。会社に戻ってから、早速環境を構築します。お客様のアプリケーションは、Linux上で動作するJavaアプリケーションだったので、Red Hat上にアプリケーションをインストール・設定して動作を確認します。

古賀 啓一郎[著]

EnterpriseZine

この記事に関連するニュース

トピックスRSS

ランキング