Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
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
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
Agenda
登壇者の紹介
課題解決の流れ
課題1
課題2
DEMO
3
1
2
3
4
5
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
登壇者の紹介
• パネリスト– Japan Oracle User Group(JPOUG)
– フリーランサー/Mac De Oracleの中の人
関口 裕士
– 日本ヒューレット・パッカード株式会社諸橋 渉
– 株式会社コーソル渡部 亮太
• 課題説明、および解説– 日本オラクル株式会社津島浩樹(津島博士)
• ファシリテーター– 日本オラクル株式会社柴田長(しばちょう先生)
4
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
本セッションでの課題解決の流れ
1. パフォーマンス問題の説明
2. 原因の候補
3. 会場投票
4. それぞれの原因の真偽を確認する為の深堀り
5. 原因の発表
6. チューニング・アイディア
7. 津島博士による解説
5
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
課題1(A社のパフォーマンス問題)
• A社では、基幹業務としてCシステムを運用している。順調に業績を伸ばしてデータ量も年々増加しているが、これまで問題なく動作していた。ところが最近になって、性能が影響して業務をこなすのが難しくなってきているため、早急に改善して欲しいとのことである。
• ここ最近のトランザクション性能を調べてもらったところ、以下のようになっていることが分かった。そこで、このシステムの性能が低下した原因の特定と改善方法を、皆さんに様々な情報を使用して考えて頂きたい。
6
時間軸(1年間)
TransactionPerSec
Response Time
直近1年のトランザクション性能の推移
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
DB TimeとはデータベースでSQLの処理にかかった時間
7
DB Time
ユーザー ブラウザ APサーバー DBサーバー
ResponseTime
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
Elapsed: 7.87 mins ≪ DB Time: 4,501.98 minsの意味
8
Elapsed07:05:34
07:13:26
7.87 mins
DB Time
4,501.98 mins
:
・・・
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
DB Time / Elapsed ≒ 572≫ CPUコア数 24の意味
9
1秒換算
・・・
・・・ ・・・
・・・
・・・
・・・
・・・ ・・・
DB Time / Elapsed ≒ 572
CPUコア数 24
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
DB Timeの内訳
10
DB Time
CPU WAIT
Server Process
Background Process
I/O Other
Read
Write
ON CPU 以外の待機していた時間Oracle Databaseは何にどれだけ時間を消費していたかを計測している
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
索引アクセスとdb file sequential read待機イベント
11
Ash 0008
David 0006
JB 0003
King 0004
Marcus 0005
Miller 0002
Stanly 0007
Woot 0001
<= David
> David
<= Miller
> Miller
<= King
> King
リーフブロック
ブランチブロック
ルートブロック
ROWID=0007
Stanly
索引エントリ
Stanly
<= King
> King
<= Miller
> Miller
Stanly 0007
Woot 0001
Stanly
テーブルEMP
Stanly
ディスクからのブロック読み込み
db file sequential read 待機イベント
ブロック
SELECT * FROM empWHERE ename = ‘Stanly’;
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
db file sequential read待機時間が伸びた理由は?
1. 検索範囲が広がった?
2. キャッシュヒット率が下がった?
3. ストレージの性能が怪しい?
12
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
Oracle Databaseの基本アーキテクチャ
13
DB Server
SGA
Storage
Buffer Cache
PMON LGWR
SP SP SP
PGA
SMON Others
LogBufferCR Block
Current Block
Undo Block
SP
DBWn
SP SP
Buffer Cache Hit
Physical Reads PhysicalWrites Redo Writes
Background Process
Server Process (Foreground Process)
Oracle Client(Application)
SQL実行
Data Files Redo LogFiles
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
課題1(解説)
• データが増加するようなシステム– いつかはリソース(CPU、メモリ、ストレージ)不足になるので監視が重要
• メモリ・チューニング(第14回)– アプリケーション・タイプで各領域(バッファ・キャッシュ、共有プール、PGA)を指定
– 自動メモリ管理/自動共有メモリ管理(アドバイザは各領域を手動で調整する)• リサイズが頻繁に発生しないように注意
• 最小サイズ指定を効果的に使用する
• 自動メモリ管理はHugePages(Linux)のとき使用できない
14
ラージ・プールバッファキャッシュ(DB_CACHE_SIZE)
共有プール
Javaプール
Streamsプール、など
Redoログバッファ
SGAPGA
スタック領域 セッション情報(UGA)
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
課題2(B社のパフォーマンス問題)
• B社では、基幹業務としてDシステムを運用している。近年、様々な事業拡張を行っていてシステムに処理の追加も行っているが、これまで問題なく動作していた。ところが最近になって、ある特定の時間だけ性能が低下して業務に影響しているため、早急に改善して欲しいとのことである。
• ここ最近の1日のトランザクション性能を調べてもらったところ、以下のようになっていることが分かった。そこで、このシステムの性能が低下した原因の特定と改善方法を、皆さんに様々な情報を使用して考えて頂きたい。
15
時間軸(1日間)
TPS
1日のトランザクション性能の推移
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
…
全表スキャンとdirect path read待機イベント
SGA
データファイル
サーバープロセス
バッファキャッシュ
PGA
データファイル
SGA
サーバープロセス
バッファキャッシュ
PGA
…
…
単一ブロック読み込み
全表スキャン …
direct path read
db file sequential read
…
パラレル全表スキャン
読込
読込
…
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
log file sync待機イベントServer ProcessがCommit要求してから、LGWRによるディスクへ書き出しが完了するまでの待機
17
DB Server
SGA
Storage
Buffer Cache
PMON LGWR
SP SP SP
PGA
SMON Others
LogBufferCR Block
Current Block
Undo Block
SP
DBWn
SP SP
Buffer Cache Hit
Physical Reads PhysicalWrites Redo Writes
Background Process
Server Process (Foreground Process)
Oracle Client(Application)
SQL実行
Data Files Redo LogFiles
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
Direct path readによる物理I/Oが多い理由は?
1. パラレル度が高すぎる?
2. パーティション・プルーニングが効いていない?
3. ストレージ性能か?
18
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
Live Demoある時間帯にパフォーマンス問題(Transaction Per Secの落ち込み)が発生
• Oracle Public Cloud 上のデータベース
– バージョン: 12.2
• Swingbench使用
– 更新系のトランザクション
20
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
課題2(解説)
• ダイレクト・パス・リード(全表スキャン)について(第13回)– バッファ・キャッシュを経由しないアクセス(I/Oが多発する)
• I/Oチューニング– まずはアクセス・データをできるだけ少なくすること• パーティション(第22回、第46回)、表圧縮(第28回)
– Oracle Database In-MemoryでもI/Oを削減(第53回、第54回)• デュアル・フォーマット(行型、列型)
• CPUコストが少ない(ディクショナリ圧縮、ストレージ索引、SIMD:Single Instruction Multiple Data)
– 最後にストレージの増強
21
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
課題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
パフォーマンス・チューニングの基本的な考え方
時間↓ = 処理量↓ / (速度 * 並列度)↑じかん = みちのり ÷ はやさ
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
Live Demoある時間帯にパフォーマンス問題(TPSの落ち込み)が発生
• Oracle Public Cloud 上のデータベース
– バージョン: 12.2
• Swingbench使用
– 更新系のOLTP処理
23
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
Live DemoDatabase In-Memoryの効果
24
Copyright © 2016 Oracle and/or its affiliates. All rights reserved.
会社帰りに参加できる、夕方開催セミナー
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
25
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.
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
Copyright © 2017 Oracle and/or its affiliates. All rights reserved.