oow2012 unconference

2,306 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,306
On SlideShare
0
From Embeds
0
Number of Embeds
1,348
Actions
Shares
0
Downloads
18
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

oow2012 unconference

  1. 1. スベらないチューニングの話おら!オラ!Oracle どっぷりチューニング生活 - Understand Oracle I/O Performance - 株式会社 インサイトテクノロジー 製品開発本部 製品企画部 新久保 浩二 新久保 浩二 Twitter: @kouji_s_0808 1
  2. 2. Dive into READ Performance本日は同一のSQL文をネタにして、同一の実行計画により、異なるI/Oパターンを発生させ、I/Oのアクセスパターンで、いろいろ、違うんだなぁーという素朴な気持ちを共有していく、世界初の試みとなります。 2
  3. 3. Dive into READ PerformanceSELECT /*+ NO_PARALLEL(L) FULL(L) */ COUNT(*)FROM LARGE_TABLE L;Rows (1st) Rows (avg) Rows (max) Row Source Operation---------- ---------- ---------- -------------------------------- 1 1 1 SORT AGGREGATE 80000000 80000000 80000000 TABLE ACCESS FULL LARGE_TABLE 3
  4. 4. Dive into READ Performanceこの男らしいSQLを味わい深いものにするために3つの異なるI/OパターンとそのI/Oパターンによるパフォーマンスの違いをお見せします。(ちなみに環境はLinux x86_64 11.2.0.3)3つの異なるI/Oパターンとは? 4
  5. 5. Dive into READ Performance そうです。 – DB FILE SCATTERED READ – DB FILE SEQUENTIAL READ – DIRECT PATH READ そもそも、これらの違いは何だった? 5
  6. 6. Oracle READ Performance – DB FILE SCATTERED READこのイベントは、ユーザー・プロセスがSGAバッファ・キャッシュにバッファを読み取り、物理I/Oコールが戻るまで待機することを意味します。db file scattered readは、データを複数の不連続メモリー位置に読み取るために散布読取りを発行します。散布読取りは通常、マルチブロック読取りです。全体スキャンの他、(索引の)高速全スキャンでも行うことができます。db file scattered read待機イベントは、全体スキャンが発生していることを識別します。バッファ・キャッシュへの全体スキャンを実行すると、読み取られたブロックは物理的に相互に接近していないメモリー位置に読み取られます。このような読取りが 散布読取りコールと呼ばれるのは、ブロックがメモリー全体に分散されているからです。… Oracle Databaseパフォーマンスチューニングガイド11gリリース2より通常、パラレルクエリーでないフルスキャンで発生することが多かった SHINKUBOパフォーマンスチューニングガイド11gリリース2より 6
  7. 7. Oracle READ Performance – DB FILE SEQUENTIAL READこのイベントは、ユーザー・プロセスがSGA内のバッファ・キャッシュにバッファを読み取り、物理I/Oコールが戻るまで待機することを意味します。順次読取りは、単一ブロック読取りです。単一ブロックI/Oは通常、索引を使用した結果です。非常にまれなケースとして、エクステントの境界のため、またはバッファ・キャッシュ内にバッファが存在するため、全表スキャン・コールが単一ブロック・コールに切り捨てられることがあります。これらの待機もdb file sequential readとして現れます。 Oracle Databaseパフォーマンスチューニングガイド11gリリース2より通常、インデックススキャンで発生 SHINKUBOパフォーマンスチューニングガイド11gリリース2より 7
  8. 8. Oracle READ Performance – DIRECT PATH READSGAのバッファ・キャッシュではなく、ディスクからPGAに直接バッファの読取りを実行しているセッションは、このイベントで待機します。I/Oサブシステムが非同期I/Oをサポートしない場合、各待機は物理読取りリクエストに対応します。I/Oサブシステムが非同期I/Oをサポートする場合、このプロセスでは読取りリクエストの発行を、PGAに存在するブロックの処理に重複させることができます。プロセスがディスクからまだ読み取られていないPGA内のブロックにアクセスしようとする場合、待機コールを発行し、このイベントの統計を更新します。したがって、待機数は必ずしも読取りリクエスト数と同じではありません(db file scattered readおよびdb file sequential readとは異なります)。 Oracle Databaseパフォーマンスチューニングガイド11gリリース2より通常、パラレルクエリー(フルスキャン)で発生することが多かった SHINKUBOパフォーマンスチューニングガイド11gリリース2より 8
  9. 9. Oracle READ Performance DB FILE SCATTERED READ/DB FILE SEQUENTIAL READ/DIRECT PATH READ Oracle Databaseパフォーマンスチューニングガイド11gリリース2より 9
  10. 10. Dive into READ Performance – DB FILE SCATTERED READ スループット重視のI/Oパターン – DB FILE SEQUENTIAL READ IOPS(レイテンシー)重視のI/Oパターン – DIRECT PATH READ スループット重視のI/Oパターン でも、DB FILE SCATTERED READとは違う 10
  11. 11. Check READ Performance baseline – スループットが高いとは “大きめのI/Oサイズで、1回のI/O処理にはちょっと 頑張ってもらって、単位時間あたりの処理量を稼ぐ” 1人で沢山、運ぶんだぜ~。 ワイルドだろ~。 – IOPSが高いとは “小さめのI/Oサイズで、1回のI/O処理を軽くしてあげ て、単位時間あたりの処理数を稼ぐ” 1人で何回も運べるんだぜ~。 ワイルドだろ~。 11
  12. 12. Dive into READ Performance – あれこれ言う前に “OSレイヤーでのI/Oパターンとスループット/IOPS を理解する必要がある” – ここを押さえないと “Oracleレイヤーの話をいくらしても、威力が半減” 12
  13. 13. Check READ Performance baseline – とりあえず… – ベンチマークとってみます。 13
  14. 14. Check READ Performance baseline – スループット Throughput (MB) 1000 900 900 800 700 600 500 400 300 200 100 13 0 sequential_1MB random_8KB 14
  15. 15. Check READ Performance baseline – IOPS IOPS 2000 1800 1742 1600 1400 1200 1000 900 800 600 400 200 0 sequential_1MB random_8KB 15
  16. 16. Check READ Performance baseline – スループット Throughput (MB) 6000 5155 5000 4000 3000 2000 900 1000 0 sequential_1MB_HDD sequential_1MB_SSD 16
  17. 17. Check READ Performance baseline – IOPS IOPS 250000 206761 200000 150000 100000 50000 1742 0 random_8KB_HDD random_8KB_SSD 17
  18. 18. Oracle READ Performance 大事なので、もう一度言います。 同一のSQL文をネタにして、 同一の実行計画により、 異なるI/Oパターンを発生させ、 I/Oのアクセスパターンで、 いろいろ、違うんだなぁーという素朴な気持ちを 共有していく、 世界初の試みとなります。 18
  19. 19. Dive into Oracle READ Performance – どうすれば良いはない。それが現実だ 19
  20. 20. Check Oracle READ Performance – Oracle I/O Pattern Elapsed Time (sec) 120 101 100 このパターンは極端 ですけど、ワイド 80 レンジスキャンが 非効率という事を 60 OSのI/O特性から この違いは何? 見た場合と一緒 40 20 20 10 0 DIRECT PATH READ DB FILE SCATTERED READ DB FILE SEQUENTIAL READ 20
  21. 21. Logical/Physical I/O vs. Direct I/O – DB FILE SCATTERED READ vs. DIRECT PATH READ – 大事なことなのでもう一度まとめます。 – 両者の違いはSGA(Buffer Cache)を経由するか否か – SGA(Buffer Cache)を経由するとは? 21
  22. 22. Logical/Physical I/O vs. Direct I/O – DB FILE SCATTERED READ vs. DIRECT PATH READ – 両者のI/Oに違いは… ありますが… – さらに違うのは、当然、キャッシュの読み込み量 – もっと顕著なのは、あのラッチの取得回数 22
  23. 23. Logical/Physical I/O vs. Direct I/O – DB FILE SCATTERED READ vs. DIRECT PATH READ DB FILE SCATTERED READ 288 919 io_submit DIRECT PATH READ 3552 io_getevents 323 pread others 3551 io_submit 6408 DB FILE SCATTERED READ(NO BUFFER) io_getevents 6325 317 others io_submit 6481 io_getevents 6491 others 23
  24. 24. Logical/Physical I/O vs. Direct I/O – DB FILE SCATTERED READ vs. DIRECT PATH READ cache buffers chains cache buffers lru chain2500000 3000 2200211 2639 25002000000 20001500000 15001000000 1000 500000 500 6136 10 0 0 DIRECT PATH READ DB FILE SCATTERED READ DIRECT PATH READ DB FILE SCATTERED READ 24
  25. 25. Logical/Physical I/O vs. Direct I/O – DB FILE SCATTERED READ vs. DIRECT PATH READ – そうです。DB FILE SCATTERED READはキャッシュ経 由ですので、どうしても、キャッシュ上のブロック の存在チェックと空き領域のチェックが必要 – さらに、状況が悪いと、DB FILE SEQUENTIAL READ が、気持よく動いているOLTP系処理のエコシステム を崩すこともあります。 * 単純にDIRECT PATH READが優れているという話 ではありません!! 25
  26. 26. Check Oracle READ Performance – Oracle I/O Pattern Elapsed Time (sec) 200 177 180 160 140 Disk I/OとBuffer Cache 120 メンテナンスのコストバランス 101 100 が変われば、パフォーマンス SSD バランスも変わる HDD 80 60 45 40 30 20 20 10 0 DIRECT PATH READ DB FILE SCATTERED READ DB FILE SEQUENTIAL READ 26
  27. 27. Tuning Oracle READ Performance – OracleのI/Oまわりをチューニングするとは – SQL文というある種アプリケーションのチューニング の重要性は疑いようもありません。が、ちょっと違 うアプローチもあるんです – そう、それはもっとプリミティブな世界 – 同じH/W、同じSQL文、同じ実行計画。でも、パ フォーマンスが大きく異なる世界。 27
  28. 28. Conclusion 無骨とも思えるOracleのI/O一つとってもプリミティブな 世界は味わい深い。 表面上の実行計画を眺めていても、解決できない問題も あるんです。 Oracleが示す各種イベントも理解しないと本質を見誤り ます。 待機イベントの理解にはOSによるプリミティブな動作が 理解の助けになります。 そんな素朴な気持ちが共有できていれば幸いです。 28
  29. 29. Q & A Questions? 29
  30. 30. Thanks ORA-03113 30

×