Technical Discussion Night ~ 今宵のテーマ : エキスパートはどう考えるか? 体感! パフォーマンスチューニング ~ Japan Oracle User Group 日本オラクル株式会社クラウド テクノロジー事業統括 Database & Exadata プロダクトマネジメント本部 Copyright 2017, Oracle and/or its affiliates. All rights reserved.
Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. 2
Agenda 1 2 3 4 5 登壇者の紹介課題解決の流れ課題 1 課題 2 DEMO 3
登壇者の紹介 パネリスト Japan Oracle User Group(JPOUG) フリーランサー /Mac De Oracle の中の人関口裕士 日本ヒューレット パッカード株式会社諸橋渉 株式会社コーソル渡部亮太 課題説明 および解説 日本オラクル株式会社津島浩樹 ( 津島博士 ) ファシリテーター 日本オラクル株式会社柴田長 ( しばちょう先生 ) 4
本セッションでの課題解決の流れ 1. パフォーマンス問題の説明 2. 原因の候補 3. 会場投票 4. それぞれの原因の真偽を確認する為の深堀り 5. 原因の発表 6. チューニング アイディア 7. 津島博士による解説 5
課題 1(A 社のパフォーマンス問題 ) A 社では 基幹業務として C システムを運用している 順調に業績を伸ばしてデータ量も年々増加しているが これまで問題なく動作していた ところが最近になって 性能が影響して業務をこなすのが難しくなってきているため 早急に改善して欲しいとのことである ここ最近のトランザクション性能を調べてもらったところ 以下のようになっていることが分かった そこで このシステムの性能が低下した原因の特定と改善方法を 皆さんに様々な情報を使用して考えて頂きたい Transaction Per Sec 直近 1 年のトランザクション性能の推移 Response Time 時間軸 (1 年間 ) 6
DB Time とはデータベースで SQL の処理にかかった時間 ユーザーブラウザ AP サーバー DB サーバー Response Time DB Time 7
Elapsed: 7.87 mins DB Time: 4,501.98 mins の意味 07:05:34 Elapsed DB Time 7.87 mins 07:13:26 4,501.98 mins : 8
DB Time / Elapsed 572 CPU コア数 24 の意味 CPU コア数 24 1 秒換算 DB Time / Elapsed 572 9
DB Time の内訳 DB Time ON CPU 以外の待機していた時間 Oracle Database は何にどれだけ時間を消費していたかを計測している CPU WAIT Server Process I/O Other Background Process Read Write 10
索引アクセスと db file sequential read 待機イベント SELECT * FROM emp WHERE ename = Stanly ; ブランチブロック <= David > David ルートブロック <= King > King Stanly <= Miller > Miller db file sequential read 待機イベント <= King > King <= Miller > Miller ディスクからのブロック読み込み リーフブロック Stanly 索引エントリ Ash 0008 David 0006 JB 0003 King 0004 Marcus 0005 Miller 0002 Stanly 0007 Woot 0001 Stanly 0007 Woot 0001 テーブル EMP ROWID=0007 ブロック Stanly Stanly 11
db file sequential read 待機時間が伸びた理由は? 1. 検索範囲が広がった? 2. キャッシュヒット率が下がった? 3. ストレージの性能が怪しい? 12
Oracle Database の基本アーキテクチャ Server Process (Foreground Process) SQL 実行 SP SP SP SP SP SP DB Server Oracle Client (Application) Buffer Cache Hit CR Block Buffer Cache Current Block Undo Block Log Buffer SGA PGA DBWn PMON SMON LGWR Others Background Process Physical Reads Physical Writes Data Files Redo Writes Redo Log Files Storage 13
課題 1( 解説 ) データが増加するようなシステム いつかはリソース (CPU メモリ ストレージ ) 不足になるので監視が重要 メモリ チューニング ( 第 14 回 ) アプリケーション タイプで各領域 ( バッファ キャッシュ 共有プール PGA) を指定 PGA SGA 共有プール スタック領域 セッション情報 (UGA) Redo ログバッファ バッファキャッシュ (DB_CACHE_SIZE) ラージ プール Java プール Streams プール など 自動メモリ管理 / 自動共有メモリ管理 ( アドバイザは各領域を手動で調整する ) リサイズが頻繁に発生しないように注意 最小サイズ指定を効果的に使用する 自動メモリ管理は HugePages(Linux) のとき使用できない 14
課題 2(B 社のパフォーマンス問題 ) B 社では 基幹業務として D システムを運用している 近年 様々な事業拡張を行っていてシステムに処理の追加も行っているが これまで問題なく動作していた ところが最近になって ある特定の時間だけ性能が低下して業務に影響しているため 早急に改善して欲しいとのことである ここ最近の 1 日のトランザクション性能を調べてもらったところ 以下のようになっていることが分かった そこで このシステムの性能が低下した原因の特定と改善方法を 皆さんに様々な情報を使用して考えて頂きたい TPS 1 日のトランザクション性能の推移 時間軸 (1 日間 ) 15
全表スキャンと direct path read 待機イベント サーバープロセス db file sequential read 単一ブロック読み込み PGA SGA バッファキャッシュ 読込 データファイル 全表スキャン パラレル全表スキャン サーバープロセス PGA SGA 読込 データファイル バッファキャッシュ direct path read
log file sync 待機イベント Server Process が Commit 要求してから LGWR によるディスクへ書き出しが完了するまでの待機 Server Process (Foreground Process) SQL 実行 SP SP SP SP SP SP DB Server Oracle Client (Application) Buffer Cache Hit CR Block Buffer Cache Current Block Undo Block Log Buffer SGA PGA DBWn PMON SMON LGWR Others Background Process Physical Reads Physical Writes Data Files Redo Writes Redo Log Files Storage 17
Direct path read による物理 I/O が多い理由は? 1. パラレル度が高すぎる? 2. パーティション プルーニングが効いていない? 3. ストレージ性能か? 18
iostat の基本的な見方 サービスタイム (iostat: svctm) 一回の I/O リクエストにおけるデバイスでの平均処理時間この値が長い場合 I/O に関連するレイヤー ( ストレージ装置 ) に問題がある 数 msec 未満 ストレージ コントローラのキャッシュに乗っている or SSD 10msec 前後 HDD までアクセスしている 数十 msec 以上 Disk Busy 等の問題あり IOPS(iostat: r/s + w/s) とレスポンスタイム (iostat: await) の関係 サービスタイムが正常時と同じだが レスポンスタイムが大きくなっている場合 I/O 要求回数が増えて待ちが発生している ストレージの性能限界に達していると推測 19
Live Demo ある時間帯にパフォーマンス問題 (Transaction Per Sec の落ち込み ) が発生 Oracle Public Cloud 上のデータベース バージョン : 12.2 Swingbench 使用 更新系のトランザクション 20
課題 2( 解説 ) ダイレクト パス リード ( 全表スキャン ) について ( 第 13 回 ) バッファ キャッシュを経由しないアクセス (I/O が多発する ) I/O チューニング まずはアクセス データをできるだけ少なくすること パーティション ( 第 22 回 第 46 回 ) 表圧縮 ( 第 28 回 ) Oracle Database In-Memory でも I/O を削減 ( 第 53 回 第 54 回 ) デュアル フォーマット ( 行型 列型 ) CPU コストが少ない ( ディクショナリ圧縮 ストレージ索引 SIMD:Single Instruction Multiple Data) 最後にストレージの増強 21
課題 2( 解説 ) パフォーマンス チューニングの基本的な考え方 処理量を減らす Index, Partitioning, Compression, Exadata Smart Scan/Storage Index, Database In-Memory Column Format/Storage Index, 実行計画の改善, 高速化 Buffer Cache, Database In-Memory, Flash Device, InfiniBand, Exafusion, 並列化 時間 = 処理量 / ( 速度 * 並列度 ) Parallel Query, Multi-Core, RAC, ASM, じかん = みちのり はやさ 22
Live Demo ある時間帯にパフォーマンス問題 (TPS の落ち込み ) が発生 Oracle Public Cloud 上のデータベース バージョン : 12.2 Swingbench 使用 更新系の OLTP 処理 23
Live Demo Database In-Memory の効果 24
会社帰りに参加できる 夕方開催セミナー Oracle Database Technology Night ~ 集え! オラクルの力 ( チカラ )~ 高可用性と高拡張性を両立する Oracle RAC ~ 改めて基礎からシンプルに理解する ~ 今宵のテーマは Oracle RAC です Oracle RAC は Oracle Database を使って高可用性と高拡張性を実現するための Key となるテクノロジーです この Oracle RAC を基礎から理解するためのポイントについてご紹介いたします お申し込み 詳細はこちら 2017 年 6 月 21 日 ( 水 )18:45~20:30 ( 受付 18:30 より ) http://www.oracle.com/goto/jpm170621 Copyright 2016 Oracle and/or its affiliates. All rights reserved. 25
Safe Harbor Statement The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. 26