OOW Tokyo 2012 Unconference つまらない STATSPACK をさらにややこしく解説してみよう

つまらない STATSPACK を
さらにややこしく解説してみよう
さらにややこしく解説してみよう

Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 1

まず、、、、

STATSPACKレポートの
時系列を予想してくだ
さい。


ヒント

SNAPSHOT１：
運用として定常的に
STATSPACK のデータは取
得している。


ヒント

SNAPSHOT2：
ある日のメンテナンス後に
OLTP 系の処理でタイムアウ
トが頻発した。
調査のために STATSPACK
レポートを取得してみた。

ヒント

SNAPSHOT3：
対応後、復旧後状況確認の
ために STATSPACK レポー
トを取得してみた。


答えは3択で、、、、

１． A→B→C
２． B→C→A
３． C→B→A


１． A→B→C
２． B→C→A
３． C→B→A


C：通常運用時
B：メンテナンス後
A：緊急対応後

３． C→B→A

環境情報（ただし、検証環境ね）

HW CPU : 4core
Mem ： 8GB
OS RHEL 5 64bit
DB Oracle Database 11.2.0.2
Enterprise Edition


構成

連携サーバ WEB・APサーバ

データベースサーバ


OLTP処理SQL（オリジナル状態）

OLTP処理SQLの統計情報
SQL Statistics
~~~~~~~~~~~~~~
% Snap
Statement Total Per Execute Total
--------------- --------------- ------
Buffer Gets: 1,052,361 116,929.0 13.72
Disk Reads: 0 0.0 .00
Rows processed: 3,600 400.0
CPU Time(s/ms): 5 558.8
Elapsed Time(s/ms): 6 674.6
:
Executions: 9


OLTP処理SQL（メンテナンス後）

SQL Statistics
~~~~~~~~~~~~~~
% Snap
--------------- --------------- ------
Buffer Gets: 1,870,864 116,929.0 2.08
Elapsed Time(s/ms): 26 1,655.3
:
Executions: 16


REPORT C（障害発生前のレポート）
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time
----------------------------------------- ------------ ----------- ------ ------
db file scattered read 1,846,915 735 0 55.9
CPU time 152 11.5
PL/SQL lock timer 1 120 ###### 9.1
db file parallel read 31 73 2358 5.6
db file sequential read 152,969 65 0 5.0
----------------------------------------- ------------ ----------- ------ ------

.。oO(「db file scatterd read」がTOPだね)


REPORT B（障害発生時のレポート）
~~~~~~~~~~~~~~~~~~ wait Call
----------------------------------------- ------------ ----------- ------ ------
CPU time 311 47.0
latch: cache buffers chains 2,635 207 78 31.2
control file parallel write 42 6 152 1.0
db file async I/O submit 69 5 67 .7
----------------------------------------- ------------ ----------- ------ ------

.。oO( I/O系の待機イベントがなくなっている。障害どころか
むしろこちらのほうが良好では？)


バッチ処理SQL（オリジナル）

バッチ処理SQLの統計情報
SQL Statistics
~~~~~~~~~~~~~~
% Snap
--------------- --------------- ------
Buffer Gets: 7,546,904 104,818.1 98.40
Disk Reads: 6,803,691 94,495.7 114.53
CPU Time(s/ms): 175 2,429.0
:
Executions: 72


バッチ処理SQL（メンテナンス後）

バッチ処理SQLの統計情報
SQL Statistics
~~~~~~~~~~~~~~
% Snap
--------------- --------------- ------
Buffer Gets: 88,412,056 116,947.2 98.09
Elapsed Time(s/ms): 728 962.7
:
Executions: 756


REPORT B（障害発生時のレポート：再び）
~~~~~~~~~~~~~~~~~~ wait Call
----------------------------------------- ------------ ----------- ------ ------
CPU time 311 47.0
latch: cache buffers chains 2,635 207 78 31.2
control file parallel write 42 6 152 1.0
db file async I/O submit 69 5 67 .7
----------------------------------------- ------------ ----------- ------ ------

.。oO(もしかして、みんな”CPU使い”になってないか？)


CPUリソースの利用状況

CPUリソースの利用状況を STATSPACKレポート
の情報から洗いなおしてみると、、、

<REPORT C> 8.6(AAS)x11.5%(CPU time)= 0.989core
<REPORT B> 6.5(AAS)x47.0%(CPU time)= 3.055core

.。oO(平均してこのぐらいはCPU使ってるなー)


OLTP処理SQLがタイムアウトした原因は？

STATSPACKレポートをながめてると、、、

1. CPUバウンドなOLTP処理がス
ローダウンしている。
2. 待機イベントの最上位がCPU
timeになっている。
3. Core数換算で1core分の空きが
ない。

対処方法

アイディア
緩募

対処方法

バッチ処理の並列度抑制
- バッチ処理SQL単体の処理時間は今回のチューニン
グで短縮している。
- バッチ処理の並列度を下げても、トータルの処理速
度は向上している。
- 今回はバッチ処理の並列度を抑えて、CPUリソース
を解放する方針で対応する。


CPUリソースの利用状況（対応後）

CPUリソースの利用状況をもう一度 STATSPACK
レポートの情報から棚卸してみた、、、

<REPORT C> 8.6(AAS)x11.5%(CPU time)= 0.989core
<REPORT B> 6.5(AAS)x47.0%(CPU time)= 3.055core
<REPORT A> 4.2(AAS)x48.2%(CPU time)= 2.024core

.。oO(おっ！？CPUリ
ソース空いた！！)


OLTP処理SQL（対応後）

SQL Statistics
~~~~~~~~~~~~~~
% Snap
--------------- --------------- ------
Buffer Gets: 1,169,290 116,929.0 2.14
: 1,655.3
Executions: 10


ちょっと寄り道（9iなあなたへ”なんちゃってAAS”）

REPORT C
~~~~~~~~~~~~~~~~~~ wait Call
----------------------------------------- ------------ ----------- ------ ------
db file scattered read 1,846,915 735 0 55.9
CPU time 152 11.5
db file parallel read 31 73 2358 5.6
db file sequential read 152,969 65 0 5.0
---------- ------ ------
合計 = 1145 87.1
100%換算合計 = 1315 100.0

Elapsed: 2.15min*60sec = 129sec 1315/129 = 10.19 (NAAS)


まとめ

- STATSPACKはDB全体を俯瞰した
情報が得られる。
- よって一部の処理の挙動は埋も
れがち。
- CPU timeが上位にいる場合は、
AASを組み合わせてCPUリソース
の利用状況を把握すべし。

まとめ

- STATSPACKレポートでAASが表示
されなくても“なんちゃって
AAS”が効果的。
愛称：NAAS（ナース）


Any Question ?
株式会社インサイトテクノロジー
山下正


OOW Tokyo 2012 Unconference つまらない STATSPACK をさらにややこしく解説してみよう

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie OOW Tokyo 2012 Unconference つまらない STATSPACK をさらにややこしく解説してみよう

Ähnlich wie OOW Tokyo 2012 Unconference つまらない STATSPACK をさらにややこしく解説してみよう (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (11)

OOW Tokyo 2012 Unconference つまらない STATSPACK をさらにややこしく解説してみよう