oow2012 unconference

1

スベらないチューニングの話

おら！オラ！ Oracle どっぷりチューニング生活

- Understand Oracle I/O Performance -

株式会社インサイトテクノロジー製品開発本部　製品企画部

新久保　浩二新久保浩二

Twitter: @kouji_s_0808

Dive into READ Performance

2

本日は

同一の SQL 文をネタにして、同一の実行計画により、異なる I/O パターンを発生させ、I/O のアクセスパターンで、いろいろ、違うんだなぁーという素朴な気持ちを共有していく、世界初の試みとなります。


3

SELECT /*+ NO_PARALLEL(L) FULL(L) */COUNT(*)

FROMLARGE_TABLE L;

Rows (1st) Rows (avg) Rows (max) Row Source Operation---------- ---------- ---------- -------------------------------- 1 1 1 SORT AGGREGATE 80000000 80000000 80000000 TABLE ACCESS FULL LARGE_TABLE


4

この男らしい SQL を味わい深いものにするために

3 つの異なる I/O パターンとその I/O パターンによるパフォーマンスの違いをお見せします。

( ちなみに環境は Linux x86_64 11.2.0.3)

3 つの異なる I/O パターンとは？


5

そうです。

– DB FILE SCATTERED READ– DB FILE SEQUENTIAL READ– DIRECT PATH READ

そもそも、これらの違いは何だった？

Oracle READ Performance

6

– DB FILE SCATTERED READこのイベントは、ユーザー・プロセスが SGA バッファ・キャッシュにバッファを読み取り、物理 I/O コールが戻るまで待機することを意味します。db file scattered read は、データを複数の不連続メモリー位置に読み取るために散布読取りを発行します。散布読取りは通常、マルチブロック読取りです。全体スキャンの他、 ( 索引の ) 高速全スキャンでも行うことができます。db file scattered read 待機イベントは、全体スキャンが発生していることを識別します。バッファ・キャッシュへの全体スキャンを実行すると、読み取られたブロックは物理的に相互に接近していないメモリー位置に読み取られます。このような読取りが散布読取りコールと呼ばれるのは、ブロックがメモリー全体に分散されているからです。…

Oracle Database パフォーマンスチューニングガイド 11g リリース 2 より

通常、パラレルクエリーでないフルスキャンで発生することが多かった

SHINKUBO パフォーマンスチューニングガイド 11g リリース 2 より


7

– DB FILE SEQUENTIAL READこのイベントは、ユーザー・プロセスが SGA 内のバッファ・キャッシュにバッファを読み取り、物理 I/O コールが戻るまで待機することを意味します。順次読取りは、単一ブロック読取りです。単一ブロック I/O は通常、索引を使用した結果です。非常にまれなケースとして、エクステントの境界のため、またはバッファ・キャッシュ内にバッファが存在するため、全表スキャン・コールが単一ブロック・コールに切り捨てられることがあります。これらの待機も db file sequential read として現れます。


通常、インデックススキャンで発生



8

– DIRECT PATH READSGA のバッファ・キャッシュではなく、ディスクから PGA に直接バッファの読取りを実行しているセッションは、このイベントで待機します。 I/O サブシステムが非同期 I/O をサポートしない場合、各待機は物理読取りリクエストに対応します。I/O サブシステムが非同期 I/O をサポートする場合、このプロセスでは読取りリクエストの発行を、 PGA に存在するブロックの処理に重複させることができます。プロセスがディスクからまだ読み取られていない PGA 内のブロックにアクセスしようとする場合、待機コールを発行し、このイベントの統計を更新します。したがって、待機数は必ずしも読取りリクエスト数と同じではありません (db file scattered read および db file sequential read とは異なります ) 。


通常、パラレルクエリー ( フルスキャン ) で発生することが多かった



9

DB FILE SCATTERED READ/DB FILE SEQUENTIAL READ/DIRECT PATH READ



10

– DB FILE SCATTERED READスループット重視の I/O パターン

– DB FILE SEQUENTIAL READIOPS( レイテンシー ) 重視の I/O パターン

– DIRECT PATH READスループット重視の I/O パターンでも、 DB FILE SCATTERED READ とは違う

Check READ Performance baseline

11

– スループットが高いとは“ 大きめの I/O サイズで、 1 回の I/O 処理にはちょっと頑張ってもらって、単位時間あたりの処理量を稼ぐ”

– IOPS が高いとは“ 小さめの I/O サイズで、 1 回の I/O 処理を軽くしてあげて、単位時間あたりの処理数を稼ぐ”

1 人で沢山、運ぶんだぜ～。ワイルドだろ～。

1 人で何回も運べるんだぜ～。ワイルドだろ～。


12

– あれこれ言う前に“OS レイヤーでの I/O パターンとスループット /IOPS を理解する必要がある”

– ここを押さえないと“Oracle レイヤーの話をいくらしても、威力が半減”


13

– とりあえず…– ベンチマークとってみます。


14

– スループット

sequential_1MB random_8KB0

100

200

300

400

500

600

700

800

900

1000

900

13

Throughput (MB)


15

– IOPS

sequential_1MB random_8KB0

200

400

600

800

1000

1200

1400

1600

1800

2000

900

1742

IOPS


16

– スループット

sequential_1MB_HDD sequential_1MB_SSD0

1000

2000

3000

4000

5000

6000

900

5155

Throughput (MB)


17

– IOPS

random_8KB_HDD random_8KB_SSD0

50000

100000

150000

200000

250000

1742

206761

IOPS


18

大事なので、もう一度言います。

同一の SQL 文をネタにして、同一の実行計画により、異なる I/O パターンを発生させ、I/O のアクセスパターンで、いろいろ、違うんだなぁーという素朴な気持ちを共有していく、世界初の試みとなります。

Dive into Oracle READ Performance

19

– どうすれば良いはない。それが現実だ

Check Oracle READ Performance

20

– Oracle I/O Pattern

DIRECT PATH READ DB FILE SCATTERED READ DB FILE SEQUENTIAL READ

0

20

40

60

80

100

120

10

20

101

Elapsed Time (sec)

このパターンは極端ですけど、ワイドレンジスキャンが非効率という事をOS の I/O特性から見た場合と一緒

この違いは何 ?

Logical/Physical I/O vs. Direct I/O

21

– DB FILE SCATTERED READ vs. DIRECT PATH READ

– 大事なことなのでもう一度まとめます。

– 両者の違いは SGA(Buffer Cache) を経由するか否か

– SGA(Buffer Cache) を経由するとは？


22


– 両者の I/O に違いは… ありますが…

– さらに違うのは、当然、キャッシュの読み込み量

– もっと顕著なのは、あのラッチの取得回数


23


64086325

323

DIRECT PATH READ

io_submitio_geteventsothers

3552

3551

919

288

DB FILE SCATTERED READ

io_submitio_geteventspreadothers

64816491

317

DB FILE SCATTERED READ(NO BUFFER)

io_submitio_geteventsothers


24


DIRECT PATH READ DB FILE SCATTERED READ0

500000

1000000

1500000

2000000

2500000

6136

2200211

cache buffers chains

DIRECT PATH READ DB FILE SCATTERED READ0

500

1000

1500

2000

2500

3000

10

2639

cache buffers lru chain


25


– そうです。 DB FILE SCATTERED READ はキャッシュ経由ですので、どうしても、キャッシュ上のブロックの存在チェックと空き領域のチェックが必要

– さらに、状況が悪いと、 DB FILE SEQUENTIAL READ が、気持よく動いている OLTP系処理のエコシステムを崩すこともあります。

* 単純に DIRECT PATH READ が優れているという話ではありません !!

Check Oracle READ Performance

26

– Oracle I/O Pattern

DIRECT PATH READ DB FILE SCATTERED READ DB FILE SEQUENTIAL READ0

20

40

60

80

100

120

140

160

180

200

1020

101

45

30

177

Elapsed Time (sec)

SSDHDD

Disk I/O と Buffer Cacheメンテナンスのコストバランスが変われば、パフォーマンスバランスも変わる

Tuning Oracle READ Performance

27

– Oracle の I/O まわりをチューニングするとは

– SQL 文というある種アプリケーションのチューニングの重要性は疑いようもありません。が、ちょっと違うアプローチもあるんです

– そう、それはもっとプリミティブな世界

– 同じ H/W 、同じ SQL 文、同じ実行計画。でも、パフォーマンスが大きく異なる世界。

Conclusion

28

無骨とも思える Oracle の I/O 一つとってもプリミティブな世界は味わい深い。

表面上の実行計画を眺めていても、解決できない問題もあるんです。

Oracle が示す各種イベントも理解しないと本質を見誤ります。

待機イベントの理解には OS によるプリミティブな動作が理解の助けになります。

そんな素朴な気持ちが共有できていれば幸いです。

Q & A

　

Questions?

29

Thanks

　

ORA-03113

30

oow2012 unconference

Technology