自己紹介 1982 年 4 月に日商エレクトロニクス株式会社入社 Sybase を使った銀行系システムの開発 保守を担当 Oracle データベースを使ったアプリケーション設計 開発 保守 およびパフォーマンス チューニングなどのコンサルティング業務を担当 Oracle データベースのデータ移行 再

Similar documents
Slide 1

スライド 1

NEC 製PC サーバ『Express5800 R120f-1E』とSanDisk『ioMemory SX /SX 』検証報告書

Microsoft Word - nvsi_050110jp_netvault_vtl_on_dothill_sannetII.doc

PowerPoint プレゼンテーション

Windows Server 2016 Hyper-V ストレージQoS機能の強化

MySQL+ioDrive2+LifeKeeper検証結果資料

富士通PCサーバ「PRIMERGY RX2530 M4」における「TeraStation TS5010 / TS3010」シリーズ動作検証報告

memcached 方式 (No Replication) 認証情報は ログインした tomcat と設定された各 memcached サーバーに認証情報を分割し振り分けて保管する memcached の方系がダウンした場合は ログインしたことのあるサーバーへのアクセスでは tomcat に認証情報

富士通社製PC サーバ『PRIMERGY』とFusion-io 社Solid State Storage『ioDrive Duo』の接続検証報告書

Microsoft Word - gori_web原稿:TrusSPSにおけるNAS OSのパフォーマンス評価.docx

スライド 1

Silk Central Connect 15.5 リリースノート

富士通株式会社製サーバPRIMERGY TX150 S7 と、イメーション株式会社製RDX USB ドッキングステーション及びRDXカートリッジの接続動作検証結果

PowerPoint プレゼンテーション

MaxGauge_診断分析プロセス

パフォーマンスレポート PCIe-SSDs

StoreEasy 1x40 RAID構成ガイド

第 7 章 ユーザー データ用表領域の管理 この章では 表や索引を格納するユーザー データ用表領域の作成や 作成後のメンテナンスに ついて解説します 1. ユーザー データ用表領域の管理概要 2. ユーザー データ用表領域作成時の考慮事項 3. ユーザー データ用表領域の作成 4. ユーザー データ

Oracle Business Intelligence Standard Edition One のインストール

PowerPoint プレゼンテーション

10年オンプレで運用したmixiをAWSに移行した10の理由

ジョブ管理ソフトウェア LoadStar Scheduler ご紹介資料 ~ システム運用品質の向上とコスト削減を実現 ~

Hadoop LZO圧縮機能の検証

Enterprise Cloud + 紹介資料

VNX ファイル ストレージの管理

ソフト活用事例③自動Rawデータ管理システム

(Microsoft PowerPoint - DSE2019_IOProfiler\203v\203\214\203[\203\223\216\221\227\277-Rev1.1)

Microsoft Word - nvsi_100222jp_oracle_exadata.doc

Microsoft Word LenovoSystemx.docx

PRIMERGY TX1320 M3 未サポートOS動作検証確認情報

Pervasive PSQL v11 のベンチマーク パフォーマンスの結果

Oracle SQL Developerの移行機能を使用したOracle Databaseへの移行

PHP 開発ツール Zend Studio PHP アフ リケーションサーハ ー Zend Server OSC Tokyo/Spring /02/28 株式会社イグアスソリューション事業部

Arcserve Backup r16 新機能 テープブロックサイズの拡張 効果実測 Arcserve Japan 1.5 版

PRIMERGY TX1330 M3 未サポートOS動作検証確認情報

パフォーマンスレポート PCIe-SSDs ioDrive®2

ストレージ パフォーマンスのモニタリング

MAGNIA Storage Server Configuration Guide

Arcserve Unified Data Protection サーバ構成とスペック見積もり方法 2016 年 06 月 Arcserve Japan Ver

PCIe SSD (PY-BS08PA*/PY-BS16PA*/PY-BS20PA*) / スイッチカード (PY-PC301)

HPE Integrity NonStop NS2300 サーバー

InfiniDB最小推奨仕様ガイド

目次 1. はじめに 用語説明 対象アダプタ P HBA/2P HBAで異なる性能 付録 ( 性能測定環境 ) P HBAでの性能測定環境 P HBAでの性能測定環境 本書の

<4D F736F F F696E74202D204E505F8E9F90A291E E815B CFC82AF B838B B838B C5E B8D5C91A E E4E41532E7

スライド 1

目次 1. はじめに SSL 通信を使用する上での課題 SSL アクセラレーターによる解決 SSL アクセラレーターの導入例 SSL アクセラレーターの効果... 6 富士通の SSL アクセラレーター装置のラインナップ... 8

PRIMERGY TX1310 M3 未サポートOS動作検証確認情報

PowerPoint プレゼンテーション

PRIMERGY TX140 S1 未サポートOS動作検証確認情報

はじめに コース概要と目的 Oracle データベースのパフォーマンス問題の分析方法 解決方法を説明します 受講対象者 データベース管理者の方を対象としています 前提条件 データベース アーキテクチャ データベース マネジメント を受講された方 もしくは同等の知識 をお持ちの方 テキスト内の記述につ

Software-Defined Storage ware Virtual SAN ware Virtual SAN

はじめに NEC と日本オラクル社は NEC のブレードサーバーシステム SIGMABLADE-H を利用し Linux プラットフォーム上で OracleRAC11g Release2 との組み合わせで線形な性能向上が可能であることを実証しました 本資料ではその検証結果について述べます 今回は 検

ActiveImage Protector 3.5

ブランドを統一 GUI とマニュアル上の製品表記をすべて Arcserve に統一 Arcserve Backup Arcserve Unified Data Protection Arcserve Replication/HA 2

性能を強化した 第 12 世代 Dell PowerEdge サーバの RAID コントローラ Dell PERC H800 と PERC H810 の OLTP ワークロード性能比較 ソリューション性能分析グループ Luis Acosta アドバンストストレージエンジニアリング Joe Noyol

Microsoft PowerPoint - ストレージ管理.ppt

アジェンダ 1 RED HAT ENTERPRISE LINUX について 2 主な新機能 3 11 まとめ

富士通社製PC サーバ『PRIMERGY』とFusion-io 社Solid State Storage『ioDrive』の接続検証報告書

SIer視点からみたハイパーコンバージドの選定構成・サイジングのポイント、注意点

Microsoft Word - qtsi_120246jp_rhev.doc

Transcription:

PCIe SSD を用いた MySQL 5.6 と 5.7 のパフォーマンス対決![+α 版 ] ~ MySQL の性能は どこまで向上するのか ~ 日商エレクトロニクス株式会社マーケティング本部 SODC グループ長井伸次

自己紹介 1982 年 4 月に日商エレクトロニクス株式会社入社 Sybase を使った銀行系システムの開発 保守を担当 Oracle データベースを使ったアプリケーション設計 開発 保守 およびパフォーマンス チューニングなどのコンサルティング業務を担当 Oracle データベースのデータ移行 再編成などを行う製品のサポート プロジェクトを担当 MySQL 互換の分散スケールアウト データベース ClustrixDB の検証 Huawei ES3000 のパフォーマンス検証 1

検証目的 Fusion-IO iodrive2 と Huawei ES3000 の基礎体力比較 MySQL v5.6 と v5.7 の性能比較 MySQL v5.7 で PCIe SSD カードの性能をどこまで引き出せるか 2

検証環境 CPU Intel Xeon CPU E5-2630 v2 @ 2.60GHz(x2) メモリ 128GB HDD 300GB x2 PCIe SSD Fusion-IO MLC PCIe iodrive2 1.2TB Huawei ES3000 1.2TB OS CentOS 6.5(2.6.32-431.el6.x86_64) データベース MySQL Community Server 5.6.21 MySQL Community Server 5.7.4 m14 負荷テストツール fio 2.1.7 ORION 11.1.0.7.0 SysBench 0.5 3

Fusion-IO iodrive2 と Huawei ES3000 の 基礎体力比較 4

カタログベースの基礎体力比較 Fusion-IO iodrive2 1.2TB Huawei ES3000 1.2TB NANDタイプ MLC MLC ランダム読取 IOPS(4K) 245,000 760,000 ランダム書込 IOPS(4K) 250,000 180,000 読み取り遅延 68µs 49µs 書き込み遅延 15µs 8µs 5

fio コマンド例 iodrive2 シーケンシャルリード 4KB の場合 6

fio による基礎体力比較 (4K) 76 万 ReadOnly IOPS ES3000 カタログスペック 25 万 ReadOnly IOPS iodrive2 カタログスペック 7

fio による基礎体力比較 (8K) 38 万 ReadOnly IOPS(4K の 1/2 の ES3000 カタログスペック ) 12.5 万 ReadOnly IOPS(4K の 1/2 の iodrive2 カタログスペック ) 8

ORION(Oracle IO Numbers) Oracle のインストールやデータベース作成不要 Oracle のワークロードをシュミレートしてストレージ I/O 性能を予測するフリーのツール Oracle と同じ I/O ソフトウェア スタックを使用 シュミレートできる主なワークロード OLTP アプリケーション DWH アプリケーション 9

ORION コマンド例 iodrive2 Small Random I/O 8KB ReadWrite 未処理 I/O の最大数 = 512 の場合 10

ORION による基礎体力比較 (1/4) 11

ORION による基礎体力比較 (2/4) 12

ORION による基礎体力比較 (3/4) 13

ORION による基礎体力比較 (4/4) 14

基礎体力比較結果まとめ fio ベンチマーク 4K の Sequential Read と Random Read で ES3000 が 77 万 IOPS を記録 ( カタログスペックとおり ) 8K の Sequential Read と Random Read で iodrive2 と ES3000 が 4K の 1/2 の IOPS を記録 ORION ベンチマーク Small Random I/O 8KB ReadWrite モードで ES3000 が 25 万 IOPS を記録 Small Random I/O で Latency に反比例して IOPS が増減 Large Sequential I/O で ES3000 が iodrive2 の 2 倍以上のデータ転送速度を記録 15

MySQL v5.6 と v5.7 の性能比較 16

検証方法 innodb のページサイズを PCIe SSD の最適サイズに設定 ファイルシステムのブロックサイズを PCIe SSD の最適サイズに設定 innodb のキャッシュサイズを実装メモリの半分に設定 上記の PCIe SSD 向けの簡単な設定で どの程度性能の差が出るかを確認 17

Sysbench コマンド例 ReadOnly モード接続数 = 512 の場合 18

MySQL v5.6 と v5.7 の性能比較の パラメータ設定 (my.cnf) パラメータ名 デフォルト チューニング innodb_buffer_pool_size 128MB 64GB innodb_flush_method fsync O_DIRECT innodb_flush_neighbors 1 0 innodb_page_size 16KB 4KB innodb_read_ahead_threshold 56 0 19

MySQL 5.6 vs 5.7 ReadOnly(ioDrive2) ファイルシステム : タイプ = EXT4 ブロックサイズ = 4K Sysbenchのパラメータ : oltp-table-size = 50,000,000 oltp-tables-count = 10 max-time = 1200 データベース : 全体サイズ = 134GB( 最適化なし ) 20

MySQL 5.6 vs 5.7 ReadOnly(ES3000) ファイルシステム : タイプ = EXT4 ブロックサイズ = 4K Sysbenchのパラメータ : oltp-table-size = 50,000,000 oltp-tables-count = 10 max-time = 1200 データベース : 全体サイズ = 134GB( 最適化なし ) 21

MySQL v5.6 と v5.7 の性能比較結果 iodrive2 22% ~ 141% のパフォーマンスUP v5.6よりもv5.7で高いtpsを記録 v5.7における使用を推奨 ES3000 9% ~ 12% パフォーマンスUP v5.6でもv5.7でもiodrive2より高いtpsを記録 v5.6でもv5.7でも安定した高い性能を発揮 22

MySQL v5.7 で PCIe SSD カードの性能を どこまで引き出せるか 23

検証方法 ページサイズ IO Capacity IO スレッド数を PCIe SSD 用に最適化 バッファプールサイズを 128MB から 48GB に変化させて PCIe SSD の性能変化と特性を確認 同時接続数は 128 イベント毎の待機時間の確認 MySQL の Performance Schema を利用 events_waits_summary_global_by_event_name テーブルからイベント毎にサマリーされた待機時間を取得 待機時間の大きい順に 15 秒毎に上位 5 個をチェック 24

待機時間確認用 PROCEDURE 25

MySQL v5.7 パラメータチューニング ページサイズ -PCIe SSDの最適サイズに設定 -ファイルシステムのブロックサイズと合わせる IO Capacityをfioの検証結果をもとに設定 IOスレッド数の増加 ログファイルサイズの拡張 読み込み / 書き込み動作をPCIe SSD 用に設定 26

MySQL パラメータ設定 (my.cnf) パラメータ名デフォルトチューニング innodb_buffer_pool_size 128MB 128MB 1GB 8GB 16GB 32GB 48GB innodb_flush_method fsync O_DIRECT innodb_flush_neighbors 1 0 innodb_io_capacity 200 100000 innodb_io_capacity_max 2000 400000 innodb_log_file_size 48M 4GB innodb_page_size 16KB 4KB innodb_read_ahead_threshold 56 0 innodb_read_io_threads 4 12 innodb_write_io_threads 4 12 innodb_doublewrite 1 1 (stores all data twice) innodb_flush_log_at_trx_commit 1 1 (full ACID compliance) データ整合性重視 27

ファイルシステムとデータベース属性 ファイルシステム属性 タイプ ブロックサイズ XFS 4K データベース属性 全体サイズ データファイルの最適化 127G 実施済 その他 I/O スケジューラ cfq (default) 28

128 Users ReadOnly モード 29

128 Users ReadWrite モード 30

待機時間の多かった wait events wait/io/file/innodb/innodb_data_file ファイル操作の完了待ち wait/io/table/sql/handler テーブル I/O 操作の完了待ち wait/synch/mutex/innodb/buf_pool_mutex 原因 : メモリー内のセマフォやオブジェクト競合 対策 :innodb_buffer_pool_instance を増やす wait/synch/rwlock/innodb/btr_search_latch 原因 : メモリー上の Hash Index の競合 対策 :innodb_adaptive_hash_index を off 31

MySQL パラメータ設定 (my.cnf) パラメータ名デフォルトチューニング innodb_buffer_pool_size 128MB 48GB innodb_flush_method fsync O_DIRECT innodb_flush_neighbors 1 0 innodb_io_capacity 200 100000 innodb_io_capacity_max 2000 400000 innodb_log_file_size 48M 4GB innodb_page_size 16KB 4KB innodb_read_ahead_threshold 56 0 innodb_read_io_threads 4 12 innodb_write_io_threads 4 12 innodb_doublewrite 1 1 (stores all data twice) innodb_flush_log_at_trx_commit 1 1 (full ACID compliance) innodb_buffer_pool_instances 8 24 innodb_adaptive_hash_index 1 0 32

ファイルシステムとデータベース属性 ファイルシステム属性 タイプ ブロックサイズ XFS 4K データベース属性 全体サイズ データファイルの最適化 127G 実施済 その他 I/O スケジューラ noop 33

チューニング結果 128 Users innodb_buffer_pool_size = 48GB iodrive2 ES3000 チューニング前 TPS チューニング後 Response Time チューニング前 チューニング後 Read Only 4,437 4,948 39.13 36.29 Read Write 2,116 2,237 94.02 90.27 Read Only 5,479 6,004 38.01 36.47 Read Write 3,580 3,804 52.73 50.55 34

iodrive2 ReadOnly モード 35

ES3000 ReadOnly モード 36

iodrive2 ReadWrite モード 37

ES3000 ReadWrite モード 38

チューニング結果 innodb_buffer_pool_size = 1G で buf_pool_mutex が激減 これに比例して TPS が増加 Response Time が減少 innodb_buffer_pool_size = 48G で待機イベント対策により ReadOnly モードで 511~525TPS アップ ReadWrite モードで 121~224TPS アップ innodb_buffer_pool_size = 48G で待機イベント対策により ReadOnly モードの上位 5 個以内に btr_search_latch イベントがランキングされなくなった 待機時間の減少に比例して QPS IOPS が向上 39

チューニング ポイント buf_pool_mutex の回避策として innodb_buffer_pool の分割が効果的 innodb_buffer_pool_size = 1G で innodb_buffer_pool が自動的に 8 分割される buf_pool_mutex を回避して PCIe SSD の性能を引き出す為に innodb_buffer_pool_size を 1G 以上にすることが推奨される innodb_buffer_pool_size が大きくなるとメモリー上の Hash Index 競合が発生することがある Hash Index 競合は innodb_adaptive_hash_index を off にすることで回避できる可能性がある 40

まとめ fio ベンチマーク ES3000 が 4K の Sequential Read と Random Read で 77 万 IOPS を記録 ( カタログとおり ) ORION ベンチマーク Small Random I/O 8KB ReadWrite モードで ES3000 が 25 万 IOPS を記録 MySQL ベンチマーク iodrive2 は v5.7 における使用を推奨 ES3000 は v5.6 でも v5.7 でも安定した高い性能を発揮 128 Users ReadWrite モードで iodrive2 が 9 万 IOPS ES3000 が 17 万 IOPS (HDD の約 800 倍 ) を記録 待機イベントの対策を実施することでパフォーマンス チューニングの費用対効果を最大化できる可能性がある 41

キャンペーンのご案内 42

Huawei ES3000 キャンペーン 気持ちいい 3 つの驚き 1. 驚きの安さ特別価格でご提供 2. 驚きの声 CyberAgent 様が積極採用! 3. 驚きの速さ本セッションにてご説明! 詳しくは 43

驚きの安さ - 特別価格でご提供 - 先出センドバック 3 年ワランティを含む価格です 44

驚きの声 -CyberAgent 様が積極採用 - PCIe SSD の用途 Slightly Ahead!! DB のパフォーマンスを向上するため PCIe SSD の導入を進めています サーバーに挿すだけで DB システムに大きな変更をしないで導入できるのがメリットです Huawei ES3000 導入経緯 サービス実装されている ボーイフレンド ( 仮 ) コストパフォーマンスの高さに驚きました 導入済みのPCIe SSDと比べ スペックやパフォーマンスに大差ないのに 導入コストが圧倒的に低いため採用しました 現在は ボーイフレンド ( 仮 ) というサービスのカスタマサポート調査用 DBと利用者向けマイページシステムのタイムラインDBで利用中です 45

46