[dbts-2014-tokyo] 目指せexadata!! oracle db高速化を目指した構成

2014/11/26

目指せExadata!! Oracle DB 高速化を目指した構成

宇佐美茂正

P2 自己紹介

• 氏名：宇佐美茂正（うさみしげまさ）

• 勤務先：ヤフー株式会社

• 職種：DBA

• 業務

– DB環境構築

– 運用業務

– チューニング

– DB監査

– Oracle関連の業務を主に担当

Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

P3 このセッションの概要

ExadataはストレージデバイスにSSD、ノード間通信、ストレージ間通信にInfiniBand、そしてストレージノード側に独自のシステム Exadata Smart Scanを搭載し最強、最高のパフォーマンスを謳っています。しかしその導入コストは非常に高く、敬遠しているユーザーも多いのが現状です。弊社では、このExadataに迫るパフォーマンスのDB システム構成を検討し、今年の２月に導入に至っています。このセッションでは、弊社のOracle高速DBシステムの構成と、行ってきた検証や性能比較、そして問題点は何処に有るのかを明らかにしたいと思います。


P4 アジェンダ

• 弊社のRDB運用状況の紹介

• SSD x InfiniBandの構成

– 具体的な構成、使っている技術 etc…

• パフォーマンス比較

-HDD x 10G、ODA、Exadataとの比較

• 問題点

– 経験した障害とその原因

• 今後

– 更なる性能改善


弊社のRDB運用状況の紹介

運用体制、規模感、etc…


P6 「全社DB」と呼ばれるプロジェクトがあります

• 全社DB

社内のRDBを統括管理するプロジェクト

弊社の各サービスの為にDB関連業務を行っています。

DB環境構築、チューニング、運用、監査、etc…

• 目的

– コスト削減 • 複数のサービス用DBを集約して運用

• DBサーバ、ストレージ等の機器の共有

– 工数削減 • サービス、開発側はDB環境構築、運用に携わらなくていい

– セキュリティ • DBアクセスの監査


P7 全社DBプロジェクトで運用しているDB

• DB数 187

• バージョン Oracle 11.2.0.2、 11.2.0.4

運用DB数 582 DBサーバ数 330

• DB数 395

• バージョン MySQL 5.1、 5.5

利用サービス広告、ヤフオク!、Yahoo!ショッピング

Yahoo!ニュース、Yahoo!トラベル Yahoo!天気、Yahoo!スポーツ Yahoo!知恵袋、Yahoo!ブログ

Yahoo!きっず、etc… Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

PCI-SSD x InfiniBandの構成

具体的な構成、使っている技術、etc…


P9 システム構成の概要図

IB HCA IB HCA IB HCA IB HCA IB HCA IB HCA

DB node 1 DB node 2 DB node 3

InfiniBand Switch

Network 01(56Gbps)

InfiniBand Switch

Network 02(56Gbps)

IB HCA IB HCA IB HCA IB HCA

PCI-SSD PCI-SSD Verident

LUN

IB HCA IB HCA

Storage node 1 Storage node 2 Storage node 3

PCI-SSD

LUN

PCI-SSD

LUN

PCI-SSD LU

N


LUN

PCI-SSD

LUN

IB HCA IB HCA

PCI-SSD

LUN

PCI-SSD

LUN

IB HCA IB HCA

PCI-SSD

LUN

PCI-SSD

LUN

IB HCA IB HCA

PCI-SSD

LUN

PCI-SSD

LUN


• データベース用のストレージデバイスは全てSSD • データベースシステム内での通信は全てInfiniBand


ハードウェアとソフトウェアの構成


P11 PCI-SSDに関して

• Virident FlashMaxIIを採用 HGST社製のSSD製品

• 特徴 Readの性能がかなり速い

カード自身にガベージ・コレクションの機能が入っておりサーバ側のCPU負荷を抑える

• RDBとの相性 Write性能は他社製品のFusion-ioの方が優れていた。

大半のDBではReadの割合が多いためReadの性能を重視


P12 InfiniBand Switch に関して

• Mellanox製 InfiniBand Switchを採用

製品名 SX6036（エッジスイッチ）

• 特徴

• 1Uスイッチに36 FDR ( 56Gbps ) ポート

• InfiniBandとEthernet接続をサポート

• IPoIBで通常のEthernetと同じように通信も可能

• 4.032Tb/s のスイッチング能力


P13 DBノードのOS & ハードウェア構成

• DBサーバ機器 Fujitsu RX200 S8

• 構成 • CPU : E5-2667 ( 6コア 12スレッド ) x 1

• メモリ : 128GB

• NIC : 1Gbps Eth x 4

Bonding用

• 富士通製 FDR InfiniBand HCA (Dual Port)

• 56Gb/s • ドライバはMellanox製のOFED

• OS ＆ Oracle Software OS : Oracle Linux 6.4

Oracle Database : 11.2.0.4

Grid Infrastructure : 11.2.0.4


P14 ストレージノードのOS & ハードウェア構成

• ストレージサーバ機器 Fujitsu RX200 S8

• 構成 • CPU : E5-2630L ( 6コア 12スレッド ) x 1

• メモリ : 32GB

• NIC : 1Gbps Eth x 2

• 富士通製 FDR InfiniBand HCA (Dual Port)

• 56Gb/s • ドライバはMellanox製のOFED

• Virident FlashMaxⅡ(2.2 TB) x 2

• OS Oracle Linux 6.4


InfiniBandネットワークでの通信

利用プロトコルとその内容


P16 本システムでのInfiniBand通信



InfiniBand Switch

Network 01(56Gbps)

InfiniBand Switch

Network 02(56Gbps)



LUN

IB HCA IB HCA


PCI-SSD

LUN

PCI-SSD

LUN

PCI-SSD LU

N


LUN

PCI-SSD

LUN

IB HCA IB HCA

PCI-SSD

LUN

PCI-SSD

LUN

IB HCA IB HCA

PCI-SSD

LUN

PCI-SSD

LUN

IB HCA IB HCA

PCI-SSD

LUN

PCI-SSD

LUN


• DBサーバ間で発生するOracle Interconnect 通信 • IPoIB

• DBサーバとストレージサーバ間で発生するSSDデバイスへのI/O通信 • iSER


P17 IPoIB (IP over InfiniBand)の概要

• InfiniBand上にIPネットワーク層を構成するサービス

• InfiniBand HCAの各ポートにIPを割り振ることが出来る

• Ethernetと同様に通信可能

• InfiniBandネットワーク経由でIP指定でEthernetと同様に処理が行えます

• 例えばSSHやSCPコマンドも使えます

• 但しこの使い方ではInfiniBand特有の低レイテンシな通信は得られません

• ただの帯域が広いEthernetと言う感じの使い方


P18 iSER (iSCSI Extensions for RDMA)の概要

• iSCSIとはリモートサーバのLUNを自分のローカルデバイスのように見せてI/Oすることが出来るプロトコルです。

• iSCSI上でRDMA通信を利用可能にしているのがiSER

• iSCSIのターゲット側の設定を変更する事で簡単に利用可能です

• パラメータ「default-driver = iser」を設定するのみ

• オペレーションや各種設定はiSCSIとほぼ同様に可能

• 通常のiSCSIに比べて低レイテンシーなI/Oが可能となる


P19 RDMA(Remote Direct Memory Access)通信

アプリケーション1

バッファ1

OS バッファ1

NIC バッファ1

Node 01

IB HCA


バッファ1

OS バッファ1

NIC バッファ1

Node 02

IB HCA

User

Kernel

Hardware

RDMA over InfiniBand

TCP/IP

• TCP/IP通信はノード内の各レイヤーでのバッファのコピーが必要 • それに比べRDMA通信は直接送信先メモリへ転送することが可能 • 通信に必要なスタックが減り低レイテンシーが実現 • また、スタックが減る為CPUの使用率低下にも期待できる


ストレージの設定

SSDデバイスをASMに登録するまでの流れ


P21 DM-Multipath の概要

• デバイスマッパーマルチパッシング

• 異なる経路で認識させた独立したデバイスを統合可能

• パスの多重化による可用性とパフォーマンスの向上が期待できる

Storage

Raid Group

Server Mapping Device

HBA 1 HBA 2

Controler 1

LUN

SAN 2

device 2 device 1

SAN 1

Controler 2


P22 新構成のストレージデバイス設定(概要図)

• 2つのInfiniBandネットワークは独立させています

• これを利用してSSDデバイスをマルチパスでDBノードに認識させます

• Active/Activeでパスを利用し且つ可用性も担保する事を狙った構成です。 • 56Gbps x 2 で 112GbpsのI/O帯域となります

IB HCA IB HCA

IB HCA IB HCA

PCI-SSD

Partition

IB Switch

Network 01

IB Switch

Network 02

Storage node

dm-01 (MULTIPATH DEVICE)

DB node

×N

56Gbps 56Gbps

iSER iSER


P23 ASMに登録する

• 作成したマッピングデバイス群でASMを構成

• ストレージレベルの障害を考慮して障害グループを設定 • ストレージノード毎にグルーピングしたDisk群で障害グループを構成

Disk1 Disk2

data1 mirror

Disk3 Disk4

data1

Disk5 Disk6

data2 mirror

data2

FAIL GROUP 02 FAIL GROUP 01

data3

data3 mirror

ASM Disk Group

FAIL GROUP 03

Storage Node 01 Storage Node 02 Storage Node 03


P24 ASMに登録する

• 作成したマッピングデバイス群でASMを構成

• ストレージレベルの障害を考慮して障害グループを設定 • ストレージノード毎にグルーピングしたDisk群で障害グループを構成

Disk1 Disk2

data1 mirror

Disk3 Disk4

data1

Disk5 Disk6

data2 mirror

data2

FAIL GROUP 02 FAIL GROUP 01

data3

data3 mirror

ASM Disk Group

FAIL GROUP 03

Storage Node 01 Storage Node 02 Storage Node 03

※ディスクグループ作成 ( 例 ) CREATE DISKGROUP <Disk Group Name> NORMAL REDUNDANCY FAILGROUP ST01 DISK ‘/dev/ST01_DISK01' NAME ST01_DISK01 FAILGROUP ST01 DISK ‘/dev/ST01_DISK02' NAME ST01_DISK02 FAILGROUP ST02 DISK ‘/dev/ST02_DISK01' NAME ST02_DISK01 ～全ディスクを羅列～ ATTRIBUTE 'compatible.asm' = '11.2.0.0.0', 'compatible.rdbms' = '11.2.0.0.0', 'compatible.advm' = '11.2.0.0.0';


P25 システム構成の全体像

Oracle ASM (Auto Storage Manager)


DB Instance 1 DB Instance 2 DB Instance 3

Oracle Grid Infrastructure

IB HCA IB HCA

PCI-SSD PCI-SSD

Partition 1 Partition 1

IB HCA IB HCA

PCI-SSD PCI-SSD


IB HCA IB HCA

PCI-SSD PCI-SSD



RAC DB

IB HCA IB HCA

PCI-SSD PCI-SSD


IB HCA IB HCA

PCI-SSD PCI-SSD


IB HCA IB HCA

PCI-SSD PCI-SSD



Network 01(56Gbps)

InfiniBand Switch InfiniBand Switch

Network 02(56Gbps)

High Performance • Storage

• SSD • 112Gb/s • RDMA

• Interconnect • 112Gb/s

High Availability • Storage

• Multipath • ASM Mirror

• Interconnect • IB NW x 2



障害時の動作テスト

サーバやIBスイッチの障害を想定したテスト


P27 実施した障害テスト一覧

大分類テスト内容想定の動作

ASMテスト (ストレージ関連の障害)

ストレージサーバのIB NW 2重障害

対象ストレージのDiskがOFFLINEとなるストレージサーバ DOWN

tgtd プロセス障害

ASM プロセス障害対象DBサーバのASM, DBインスタンスで再起動が発生する

RACテスト

サービス NW 2重障害生存DBノードにVIPのフェイルオーバー対象DBサーバのDB ServiceはDOWNする

DBサーバの IB NW 2重障害

対象DBサーバがクラスタから切り離される DBサーバ DOWN

DB インスタンスプロセス障害対象DBインスタンスの再起動が発生

IBスイッチテスト IBスイッチ片系障害マルチパスの対象パス切り離される DBサーバダウンは発生しない


P28 障害テストで想定外の挙動となった点

• マルチパスのパス障害時の挙動

– 特定ストレージノードのDOWN

• 想定

– 対象ストレージノードのDisk OFFLINEが発生

• 実際

– Disk GroupがDismountされ全クラスターダウン

– IBスイッチの片系障害

• 想定

–パスの切り離しが発生するがクラスターは稼動を続ける

• 実際

– Disk GroupがDismountされ全クラスターダウン


P29 パスの切り離しがうまく行かなかった原因

• ASMのメタデータ更新に失敗 – 11.2.0.4ではASMのメタデータ更新のタイムアウトが15秒

– これが出来なかった場合、対象Disk GroupはDismountされる

– パスの障害検知はこの時間内に完了させる必要がある

• マルチパス障害検知に関わる設定 – iSCSI

• 死活監視間隔 5秒 – node.conn[0].timeo.noop_out_interval = 5

• 死活監視がエラーと判断するまでの待ち時間 5秒 – node.conn[0].timeo.noop_out_timeout = 5

• 復旧待ち時間 120秒 – node.session.timeo.replacement_timeout = 120

iSCSIセッションが切れた際にエラーと判断されるまでに、126～130秒

– Multipath • パスのチェック間隔 5秒

– polling_interval = 5

• パスチェック時のリトライ 0回 – no_path_retry = 0

パスの障害と判断されるまでに、1～5秒

パスの経路障害と判断されるまでに、127～135秒掛かる Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

パフォーマンスの比較

• HDD x 10G

• ODA

• Exadata

• SSD x IB


P31 HDD x 10G

DB Storage 02


DB Storage 01 DB Storage 03

Storage Network 10G Ethernet

Interconnect Network 1G Ethernet

【機器】 • DBサーバ

• 台数 : 3台 • 機種 : HP DL360 G7 • CPU : E5-2643(4コア)x2 • メモリ : 72GB • OS : Oracle Linux 5.9

• DB Storage : NetApp • 台数 : 3台 • 機種 : FAS 3270 • 構成Disk : SAS HDD (15K rpm) x 51

【ネットワーク】 • ストレージ間ネットワーク(SAN)： 10G Ethernet (10BASE-SR) • ノード間通信ネットワーク(Interconnect NW)： 1G Ethernet


P32 ODA ( Oracle Database Appliance)

Oracleのアプライアンス製品【機器】 • DBサーバ

• 台数 : 2台 • CPU : E5-2697(12コア) x 2 • メモリ : 256GB

• DB Storage • 機種 : 製品付属のストレージシェルフ • 構成Disk

• SAS HDD (10K rpm) x 20 ( データファイル格納用 ) • SSD x 4 ( Redo 格納用 )

【ネットワーク】 • ストレージ間ネットワーク(SAN)： 6Gb/s (SAS-2 HBA) • ノード間通信ネットワーク(Interconnect NW)： 1G Ethernet (クロスケーブル)


P33 Exadata (X2-2 Full RAC)

Oracleのアプライアンス製品【機器】 • DBサーバ

• 台数 : 8台 • CPU : X5670(6コア) x 2 • メモリ : 96GB

• DB Storage • 機種 : 製品付属のストレージサーバ群 • 台数 : 14台 • 構成Disk

• SAS HDD (15K rpm) x 28 ( データファイル＆ REDO 格納用 ) • Flashデバイス ( Oracle DB 2次キャッシュ用 )

【ネットワーク】 • ストレージ間ネットワーク(SAN)兼ノード間通信ネットワーク(Interconnect)

• InfiniBand QDR 40Gb/s


IO性能比較

秒間 I/O, 転送量, レイテンシ


P35 IO性能の測定方法

• CALIBRATE_IOプロシージャーを利用

• DBシステムのストレージ性能の測定が可能 • システムが耐えられる秒間 I/Oリクエスト

• システムが耐えられる秒間 I/O MB

• MAX I/O時のレイテンシ

SET SERVEROUTPUT ON DECLARE lat INTEGER; iops INTEGER; mbps INTEGER; BEGIN -- DBMS_RESOURCE_MANAGER.CALIBRATE_IO (<DISKS>, <MAX_LATENCY>, iops, mbps, lat); DBMS_RESOURCE_MANAGER.CALIBRATE_IO (8, 10, iops, mbps, lat); DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops); DBMS_OUTPUT.PUT_LINE ('latency = ' || lat); dbms_output.put_line('max_mbps = ' || mbps); end; /


P36 MAX MBPS (最大秒間転送量)

4587

3085

19771

17516

0

5000

10000

15000

20000

25000

ODA HDD x 10G Exadata SSD x IB

MAX MBPS


P37 MAX IOPS (最大秒間 I/O リクエスト)

17112

268875

111338

1153229

0

200000

400000

600000

800000

1000000

1200000

1400000


MAX IOPS


P38 MAX IOPS時の平均待機時間(ミリ秒)

8

0

8

0 0

1

2

3

4

5

6

7

8

9


LATENCY

レイテンシ 1ミリ秒以下

レイテンシ 1ミリ秒以下


SQLの性能比較


P40 SQLパフォーマンスの比較方法

• Swingbench • 概要

• Oracleに擬似的に負荷を掛けるアプリのように動作する

• Java動作

• テーブルとデータの作成、スループットの表示をやってくれる

• ベンチマークの種類

下記のテンプレートが用意されている

カスタマイズも可能

名前説明 Read/Write 割合 Max size

Order Entry TCP-C(OLTP系) 6 : 4 100GB

Calling Circle Oracle版 OLTP ベンチマーク

7 : 3 100GB

Stress Test 単純な負荷を掛けるストレステスト

5 : 5 -

Sales History TCP-Hベース(DWH系) 10 : 0 1TB

※ この測定に関してはExadata(X2-2)環境では取得できていません


P41 秒間トランザクションの比較 (TPS)

293

870 966 981 649

2539

3756 3710

2030

7880 7932

6821

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10 100 300 500

Session

TPS

ODA

HDD x 10G

SSD x IB


P42 検証時のCPU使用率(%)

20

40

50

60

10

60

70 70

40

100 100 100

0

10

20

30

40

50

60

70

80

90

100

10 100 300 500

Session

CPU

ODA

HDD x 10G

SSD x IB


P43 平均レスポンスタイム(ミリ秒)

36

219

689 1153

11

33

68 95

4

13

49

106

1

10

100

1,000

10,000

10 100 300 500

Session

Average Responce Time

ODA

HDD x 10G

SSD x IB


P44 TOP5 待機イベントの割合(10 Session時)

db file

sequential

read

DB CPU

enq: KO -

fast object

checkpoint

direct path

read db file

parallel

read

ODA

db file

sequential

read

log file sync

gc current

block 2-

way

gc buffer

busy

acquire

read by

other

session

HDD x 10G

DB CPU

db file

sequential

read

log file sync

gc cr grant

2-way

gc current

block 2-way

SSD x IB

■ ODA db file sequential read のWaitが多い ■ HDD x 10G db file sequential read のWaitが多い ■ SSD x IB db file sequential read のWaitの割合が減少 CPU処理時間が50%


P45 TOP5 待機イベントの平均待機時間(ms)

ODA HDD x 10G SSD x IB

db file sequential read

7 db file sequential read

3 DB CPU -

DB CPU - log file sync 1 db file sequential read

0

enq: KO – fast object checkpoint

9 gc current block 2-way

0 log file sync 0

direct path read

7 gc buffer busy acquire

3 gc cr grant 2-way

0

db file parallel read

10 read by other session


0

10 Session 時

SSD x IBの構成は処理における各イベントの待機時間が少なくなっています Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

P46 TOP5 待機イベントの平均待機時間(ms)

ODA HDD x 10G SSD x IB

db file sequential read

15 db file sequential read

8 Log file sync 3

direct path read

143 gc buffer busy acquire

8 DB CPU -

enq: KO – fast object checkpoint

167 enq: TX – row lock content

11 Db file sequential read

1

DB CPU - log file sync 1 gc cr grant 2-way

0

db file parallel read

27 read by other session


0

100 Session 時

10セッション時と同様に、 SSD x IBの構成は処理における各イベントの待機時間が少なくなっています


新構成へ移行したDBの性能

HDD x 10G ⇒ SSD x IB


P48 SQLの実行時間とI/O時間の比較

対象SQL 比較項目従来構成 HDD x 10G

新構成 SSD x IB

SQLその１

実行時間(s) 10.63 0.10

I/O時間 10.41 0.07

DB CPU(%) 0.6 32.1

I/O(%) 97.9 70.6

SQLその2

実行時間(s) 20.29 0.13

I/O時間 20.18 0.09

DB CPU(%) 0.5 33.1

I/O(%) 99.5 70.6

• パフォーマンスが問題となっていたSQLの性能を比較しました • SQLその１

• 実行時間が10秒掛かっていたものが0.1秒に減少 • I/Oに掛かっていた時間が大幅に減少した為

• SQLその２

• 実行時間が20秒掛かっていたものが0.1秒に減少 • I/Oに掛かっていた時間が大幅に減少した為


P49 待機クラスの比較

Wait Class 項目従来構成 HDD x 10G

新構成 SSD x IB

User I/O DB Time(%) 79.3 3.5

Avg Wait(ms) 53 0

Commit DB Time(%) 4.3 0.2

Avg Wait(ms) 83 1

Cluster DB Time(%) 3.7 0.4

Avg Wait(ms) 12 0

DB CPU DB Time(%) 13.7 56.3

Avg Wait(ms) - -

• 移行前の環境で上位に来ていた待機クラスで比較

• User I/Oの待機クラスの割合が80%を占めていたが移行後は3.5%に減少 • Commitの待機クラスも減少 • Cluster ( クラスタ関連処理ノード間通信 etc…)も減少

• 他の待機クラスが減りDB処理時間の割合はCPUが大半を占めるようになった


P50 性能比較のまとめと価格面のメリット

【パフォーマンス】

• 速い！

– SQL実行時間が平均で10倍速い

–物理読込が多いSQLでは100倍程速かった

– IO関連の待機イベントが大幅に減っている

– Cluster系の待機イベントに関しても多少改善が見られた

【価格】

• 弊社の従来構成とほぼ同額で導入可能


問題点

経験した障害とその原因


P52 ストレージ間通信の失敗による障害

• I/Oの失敗が続きOracleの自発的パニックリブート発生

※Voting DiskへのI/Oやノード間通信が規定時間以上途絶えるとOracleの自発的パニックリブートが発生します


DB node 2 DB node 3

InfiniBand Switch

Network 01(56Gbps)

InfiniBand Switch

Network 02(56Gbps)



LUN

IB HCA IB HCA


PCI-SSD

LUN

PCI-SSD

LUN

PCI-SSD

LUN


LUN

PCI-SSD

LUN

DB node 1

I/O Error

DOWN


P53 InfiniBand通信の設定が原因


バッファ1

IB HCA

Node 01


バッファ1

IB HCA

Node 02

IP over InfiniBand

RDMA通信

User

Hardware

• 通信時のバッファが連続領域で確保されていました • IPoIBの設定が絡んでいます

• メモリが枯渇すると通信に失敗する可能性が高まります

• 設定を変える事でこれは回避できる

※メラノックス製InfiniBandスイッチ、ドライバの不具合ではありません Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

今後

更なる性能改善を狙ってみたい


P55 RDS over InfiniBand

• Oracleのインターコネクト通信ではUDPと「RDS」が利用可能

• RDS(Reliable Datagram Socket)

– InfiniBand上でRDMA通信が可能

• 導入するとCluster関連の待機イベントの改善が期待できる


DB node 2 DB node 3

InfiniBand Switch

Network 01(56Gbps)

InfiniBand Switch

Network 02(56Gbps)

DB node 1

Oracle Interconnect UDP ↓

RDS


P56 Smart Flash Cacheの利用

Oracle ASM (Auto Storage Manager)

DB Instance

Datafiles


Flash Cache

• PCI-SSD x InfiniBandで構成したDiskグループをOracleの二次キャッシュ領域として利用

• 設定は容易（DBパラメータ）

• DB_FLASH_CACHE_FILE ( ASM or OS上でパスを指定 )

• DB_FLASH_CACHE_SIZE ( サイズを指定 )

• 二次キャッシュの方が性能が出るのではないか？


最後に


P58 I/O性能が改善される事によるメリット

【従来構成】

• 従来構成ではI/O処理がかなりネックになっていた

• これはDBシステムが理想とする本来の姿ではない • CPUライセンスを払っているのに実際ネックになっているのはI/O

• CPUリソースを使い切る前にI/Oが限界を迎えてしまう

• 増設や移行計画はCPUリソースを使い切った末に検討されるのが理想

【新構成】

• 新構成ではI/Oがネックになっていた部分が解消された

• その結果DB処理時間の大半がCPU実行時間に変わっています

• CPUリソースを使い切る理想的なシステム構成になった

• 高いOracleのポテンシャルを最大限に発揮できるようになった


ご清聴ありがとうございました

[dbts-2014-tokyo] 目指せexadata!! oracle db高速化を目指した構成

Technology