ボトルネックの把握
今回のサーバでは、オンライン処理にて、参照処理だけでなく、更新処理も多く行われるシステムであり、画面遷移、登録処理の両方が遅いという状態でした。
まずは、Oracleサーバの状況把握のため、プロセッサ・メモリ・ディスクなどのシステムリソースの使用状況と、Oracleの各種情報を確認しました。
その結果、今回のサーバでは、主に以下の点から、ディスク装置がボトルネックとなっていることが確認できました。
・デバイスの待ち要求数が非常に高い
・Oracleバッファヒット率は大きく低下していない
・Oracleデータファイルへのアクセスが同一ドライブに集中している
・Redoログ待ち時間が長い
これらの結果から、ディスク装置の数と回転数を増強したディスクに変更し、かつOracleデータファイルの分散を行うことになりました。以下にディスク装置変更前後において、顕著な変化があったグラフを掲載いたします。
デバイス待ち要求数
本サーバはWindowsサーバであったことから、ディスクの指標として、デバイス待ち要求数を使用しました。
デバイスの処理は逐次処理となるため、負荷が高くなるとデバイスへの待ち要求数が増加します。
【図1：＜ディスク増強・データファイル分散前＞デバイス待ち要求数】
データファイルを格納しているTドライブに負荷が集中し、オンライン時間帯である日中帯には、多くのデバイス待ちが発生しており、50を超えるような時間帯も存在しています。
【図2：＜ディスク増強・データファイル分散後＞デバイス待ち要求数】
データファイルをTドライブ以外のSドライブにも分散を行っており、大半の時間帯で、デバイス待ち要求数は5以下に減少しております。
Oracle Redoログごとの待ち時間
Redoログは各トランザクションで変更されたデータの変更履歴が記録されています。この動作としては、一度メモリ内のバッファにためて、主に以下のタイミングで、Redoログファイルへの書き込みが行われます。
・トランザクションのCOMMIT時
・REDOログバッファの1/3に達した場合
・タイムアウト発生時
・バッファキャッシュ内のデータがデータファイルに書き出される時
Redoログバッファに書き込む速度が、Redoログファイルに書き込む速度を上回る場合、Redoログ待ちが発生し、その期間はデータベースの処理が行われない状態となり、レスポンス悪化を引き起こす可能性があります。
【図3：＜デバイス増強・データファイル分散前＞Redoログ毎の待ち時間】
常時2秒から4秒のRedoログ待ちが発生しており、長い時には10秒以上の値となっている時間帯も存在していました。
【図4：＜デバイス増強・データファイル分散後＞Redoログ毎の待ち時間】
Redoログ待ち時間は大きく改善されており、大半の時間帯で1秒未満、最大でも2秒未満となっておりました。
まとめ
今回は、更新系の処理が非常に多く、ディスクに多くの負荷がかかっていることから、データファイルの分散とディスク装置の増強を実施した事例です。
Oracleのデータファイル分散は、以下のポイントが重要であり、大きな効果が見込まれます。
・使用状況の高いデータファイルを把握し、別ディスクに配置する
・Redoログファイルと実際のデータファイルを別ディスクに分ける
今回は、上記対応の他に、高速なディスクへの移行も実施しておりますが、チューニング前後のパフォーマンスデータを比較し、大きな改善が見られた事例としてご紹介させていただきました。
|
