Oracle の負荷テストについてメモ

• 良すぎるキャッシュヒット率に注意
  • 一部のデータにしかアクセスしない場合、全データがキャッシュに載り、良すぎるキャッシュヒット率が計測される。
• キャッシュの状態を適切に再現する
  • キャッシュの状態を適切に再現するためにテスト手順、テストデータ、テスト環境のスペックについて注意する必要がある。
  • オンライン時間帯にアクセスしない表に対して検索する夜間バッチ処理の場合、DB／OS／ストレージのキャッシュをクリアしてからパフォーマンステストを実施する。
  • オンライン時間帯に頻繁に参照されるマスタ表の場合、テストアプリケーションを空回しし、本番稼動時のキャッシュ状態を再現してから測定を開始する。
• テストデータのサイズはキャッシュサイズに比例して用意する
  • キャッシュサイズ、データサイズが本番環境と異なる環境でテストを実施する場合は、比率が本番環境と同等になるようにする。
• 過剰キャッシュヒットを見破るには
  • STATSPACK の Instance Activity の physical reads および physical writes と DB のブロックサイズの積がバッファキャッシュのサイズと比較して小さすぎる場合、テストデータの量が少なすぎるまたは負荷シミュレータ検索対象とするデータ範囲が狭すぎる疑いがある。
  • STATSPACK の File IO Stats で一部のデータファイルに物理I/Oが偏っている場合、負荷シミュレータが一部のデータにしかアクセスしていない可能性がある。
  • STATSPACK の SQL ordered by Gets、SQL ordered by Reads、SQL ordered by Executions などの Gets per Exec、Reads per Exec、Rows per Exec がゼロやゼロに近い値になっていたり、本番システムにおける問い合わせの処理パターンと合致しない値になっている場合は、試験結果の信憑性が疑われる。
• 収集しておいたほうが良い情報
  • STATSPACK（レベル7）
  • OS情報（sar、vmstat、iostat、vxstatなど）
    • CPU使用率
    • CPUのrunキュー長
    • スワッピング状況
    • カーネルメモリ使用状況
    • ユーザメモリ使用状況
    • ディスクI/O量
    • ディスクビジー率
    • 平均サービス時間
    • 平均待ち時間
• テスト前にやるべきこと
  • 統計情報の収集
  • テスト環境を無断で使用している者がいないか確認する。

門外不出のOracle現場ワザ (DB Magazine SELECTION) P.89-108 より