technical discussion night · 2020. 7. 30. · iostatの基本的な見方...

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


Agenda

登壇者の紹介

課題解決の流れ

課題１

課題２

DEMO

3

1

2

3

4

5


登壇者の紹介

• パネリスト– Japan Oracle User Group（JPOUG）

– フリーランサー/Mac De Oracleの中の人

関口裕士

– 日本ヒューレット・パッカード株式会社諸橋渉

– 株式会社コーソル渡部亮太

• 課題説明、および解説– 日本オラクル株式会社津島浩樹（津島博士）

• ファシリテーター– 日本オラクル株式会社柴田長（しばちょう先生）

4


本セッションでの課題解決の流れ

1. パフォーマンス問題の説明

2. 原因の候補

3. 会場投票

4. それぞれの原因の真偽を確認する為の深堀り

5. 原因の発表

6. チューニング・アイディア

7. 津島博士による解説

5


課題１（A社のパフォーマンス問題）

• A社では、基幹業務としてCシステムを運用している。順調に業績を伸ばしてデータ量も年々増加しているが、これまで問題なく動作していた。ところが最近になって、性能が影響して業務をこなすのが難しくなってきているため、早急に改善して欲しいとのことである。

• ここ最近のトランザクション性能を調べてもらったところ、以下のようになっていることが分かった。そこで、このシステムの性能が低下した原因の特定と改善方法を、皆さんに様々な情報を使用して考えて頂きたい。

6

時間軸（1年間）

TransactionPerSec

Response Time

直近1年のトランザクション性能の推移


DB TimeとはデータベースでSQLの処理にかかった時間

7

DB Time

ユーザーブラウザ APサーバー DBサーバー

ResponseTime


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

:

・・・


DB Time / Elapsed ≒ 572≫ CPUコア数 24の意味

9

1秒換算

・・・

・・・・・・

・・・

・・・

・・・

・・・・・・

DB Time / Elapsed ≒ 572

CPUコア数 24


DB Timeの内訳

10

DB Time

CPU WAIT

Server Process

Background Process

I/O Other

Read

Write

ON CPU 以外の待機していた時間Oracle Databaseは何にどれだけ時間を消費していたかを計測している


索引アクセスと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’;


db file sequential read待機時間が伸びた理由は？

1. 検索範囲が広がった？

2. キャッシュヒット率が下がった？

3. ストレージの性能が怪しい？

12


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


課題１（解説）

• データが増加するようなシステム– いつかはリソース（CPU、メモリ、ストレージ）不足になるので監視が重要

• メモリ・チューニング（第14回）– アプリケーション・タイプで各領域（バッファ・キャッシュ、共有プール、PGA）を指定

– 自動メモリ管理/自動共有メモリ管理（アドバイザは各領域を手動で調整する）• リサイズが頻繁に発生しないように注意

• 最小サイズ指定を効果的に使用する

• 自動メモリ管理はHugePages(Linux)のとき使用できない

14

ラージ・プールバッファキャッシュ（DB_CACHE_SIZE）

共有プール

Javaプール

Streamsプール、など

Redoログバッファ

SGAPGA

スタック領域セッション情報（UGA）


課題２（B社のパフォーマンス問題）

• B社では、基幹業務としてDシステムを運用している。近年、様々な事業拡張を行っていてシステムに処理の追加も行っているが、これまで問題なく動作していた。ところが最近になって、ある特定の時間だけ性能が低下して業務に影響しているため、早急に改善して欲しいとのことである。

• ここ最近の1日のトランザクション性能を調べてもらったところ、以下のようになっていることが分かった。そこで、このシステムの性能が低下した原因の特定と改善方法を、皆さんに様々な情報を使用して考えて頂きたい。

15

時間軸（1日間）

TPS

1日のトランザクション性能の推移


…

全表スキャンとdirect path read待機イベント

SGA

データファイル

サーバープロセス

バッファキャッシュ

PGA

データファイル

SGA

サーバープロセス

バッファキャッシュ

PGA

…

…

単一ブロック読み込み

全表スキャン …

direct path read

db file sequential read

…

パラレル全表スキャン

読込

読込

…


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


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


課題２（解説）

• ダイレクト・パス・リード（全表スキャン）について（第13回）– バッファ・キャッシュを経由しないアクセス（I/Oが多発する）

• I/Oチューニング– まずはアクセス・データをできるだけ少なくすること• パーティション（第22回、第46回）、表圧縮（第28回）

– Oracle Database In-MemoryでもI/Oを削減（第53回、第54回）• デュアル・フォーマット（行型、列型）

• CPUコストが少ない（ディクショナリ圧縮、ストレージ索引、SIMD:Single Instruction Multiple Data）

– 最後にストレージの増強

21


課題２（解説）

• 処理量を減らす

– 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 DemoDatabase 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

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

technical discussion night · 2020. 7. 30. · iostatの基本的な見方...

Documents