SlideShare a Scribd company logo
1 of 67
Download to read offline
dimSTATから見る
ベンチマーク
MyNA会(2015年8月)
自己紹介
• いとう ひろゆき
• サーバ運用/保守が仕事
• ネットワークからOS、ミドルウェアまでアプリケーション
以外は何でも面倒を見ます(程度の差はあります)
• MySQL好き、酒好き
@kamipoさん、
Oracle Aceおめでとうございます
お題
• dimSTATって何?
• dimSTATの簡単な使い方
• dimSTATのグラフを見てみる
• dimSTATから見るベンチマーク
dimSTATって何?
• MySQLに関するブログを書かれているDimitriさん作成のモニ
タリングツール(http://dimitrik.free.fr)
• こんなグラフ見た事ありませんか?
• MySQLのperformance_schemaに関するグラフも生成可能
(waitに絡む物)
参考1: http://dev.mysql.com/doc/refman/5.6/ja/wait-summary-tables.html
参考2: http://dev.mysql.com/doc/refman/5.6/ja/performance-schema-instrument-
naming.html
• events_waits_summary_global_by_event_nameテーブルから
情報を取得
• COUNT_STARとSUM_TIMER_WAIT
• その他モニタリングツール(Cacti, muninとか)で標準で収集出来
る物はだいたい収集可能
• インストール方法についてははてダに以前書いたので使ってみた
い方は参考にして下さい
(http://d.hatena.ne.jp/hiroi10/20150523/1432345143)
dimSTATの
簡単な使い方
dimSTATのグラフを見てみる
1台の場合、そのまま Analyze をクリック
1. Hostの横のチェックボックスを選択
2. 見たいグラフの項目をクリック
項目を全部表示するために”More>>>”をクリック
大量に出て来た中から wait/synch/* の大きい方から10件のグ
ラフを描画します
• 上位10件のみ表示するため Select TOP-[10]にチェック
• 絞り込みたいパターンとして wait/synch/* を入力し
Use Select Pattern にチェック
グラフ描画する条件を選択します。
今回は LOG Messages で範囲を指定しています。
Waits/sec を表示するため、Values の所にチェックを入れて
Go! をクリック
• 以上が基本的な操作
• Time/sec をチェックした場合は待ち時間が長いTOP10がグ
ラフ描画されます
dimSTATの簡単な使い方
1. インストール
2. 取得したいサーバの登録
3. 取得開始
4. ベンチマークとか実行
5. 停止
6. グラフを見る(取得中も可)
dimSTAT利用時の設定
• my.cnfに以下設定を行う事が推奨となります
• performance_schema = ON (5.6, 5.7ならデフォルトでON)
• performance_schema_instrument=‘%sync%=on'
• innodb_monitor_enable = 'all'
デモ
dimSTATから見る
ベンチマーク
ベンチマーク環境
• HP DL360p G8v2 (ベンチマークサーバ)
• CPU Intel Xeon E5-2643 v2 @ 3.50GHz x 2(1CPU =
6Core)
• MEM 8GB x 8 = 64GB
• ioDrive2 785GB
• Driver version: 3.2.6 build 1212, Firmware v7.1.15, rev 110356 Public
• NIC Intel I350
• OS CentOS 6.6(2.6.32-504.12.2.el6.x86_64)
• HP DL360 G7(ベンチマーククライアント)
• CPU Intel Xeon L5640 @ 2.27GHz (2CPU = 6Core x 2)
• MEM 4GB x 12 = 48GB
• NIC Broadcom NetXtreme II BCM5709
• OS CentOS 5.9 (2.6.18-348.16.1.el5)
• MySQL バージョン(RPM版使用)
• 5.7.8 RC 及び 5.6.26
• ベンチマークツール
• LinkBench
• データ量 218GB
FBWorkload.propertiesでmaxid1 = 200000001
• ファイルシステム
• xfs, ext4
マウントオプション: defaults,nobarrier,discard
計測内容
1. 基本MySQLは同じ設定
未設定によるデフォルトは対象バージョン準拠
2. MySQL 5.7, 5.6それぞれでxfs, ext4でベンチマークを実施
3. LinkBenchの条件はリクエスト数のみ指定
✦ ./bin/linkbench -c config/MyConfig.properties -D
requests=600000 -r
✦ リクエスト数のデフォルト値は1000000
✦ スレッド数のデフォルトは100
ポイントとなるパラメータ
• innodb_io_capacity = 18000
• innodb_io_capacity_max = 23000
• innodb_log_file_size = 1G
• innodb_log_files_in_group =16 (default 2)
• innodb_buffer_pool_instances = 23 (default 8)
• innodb_buffer_pool_size = 46G
• innodb_lru_scan_depth = 6000 (default 1024)
• innodb_page_size = 4k (default 16k)
• innodb_adaptive_flushing = 1 (default 1)
ベンチマーク結果
• 5.6.26より5.7.8の方がxfs, ext4どちらでも高スコア
• 同一バージョンでの比較ではxfsの方が高スコア
• 5.6.26(ext4)が何故遅いのかdimSTAT等から見ていきます。*1,
*2のスコアへの変更点も紹介します。
xfs ext4
5.7.8
5.6.26
5.6.26(*1)
5.6.26(*2)
同一設定のグラフ
5.7.8 xfs 5.7.8 ext4 5.6.26 ext45.6.26 xfs
• Checkpoint-ageがext4の場合は張り付く傾向にあり、5.6.26の場
合は更にHistory Lengthが伸びているためundoのpurgeが追いつ
いていないと考えられる。
innodb_max_purge_lag = 100000を設定しているため、History
Lengthはその辺りで頭打ちします(innodb_max_purge_lag_delayは
1000000)
5.7.8 xfs 5.7.8 ext4 5.6.26 ext45.6.26 xfs
• 5.6.26 ext4の性能劣化が発生したタイミングからほぼほぼ
purge_invokedが増えていないため、これを改善出来れば性
能が改善されると考えられる。History Lengthも増えてるい
る事からも安定してpurge出来れば安定すると推測。
5.7.8 xfs 5.7.8 ext4 5.6.26 ext45.6.26 xfs
purge状況
バッファのフラッシュ状況
• buffer_flush_batch_num_scanと
buffer_LRU_search_scannedがやたらと増加している
5.7.8 xfs 5.7.8 ext4 5.6.26 ext45.6.26 xfs
• ./storage/innobase/srv/srv0mon.cc からコメント抜粋
• purge_del_mark_records
• Number of delete-marked rows purged
• purge_invoked
• Number of times purge was invoked
• purge_undo_log_pages
• Number of undo log pages handled by the purge
• purge_upd_exist_or_extern_records
• Number of purges on updates of existing records and
updates on delete marked record with externally stored
field
• buffer_flush_batch_num_scan
• Number of times buffer flush list flush is called
• buffer_LRU_search_scanned
• Total pages scanned as part of LRU search
2パターンの対応
1. innodb_io_capacity, innodb_io_capacity_maxを極端に増やしてみる
• innodb_io_capacity = 55000
• innodb_io_capacity_max = 60000
• 参考: 14.13.8. InnoDB マスタースレッドの I/O レートの構成
(http://dev.mysql.com/doc/refman/5.6/ja/innodb-performance-thread_io_rate.html)
2. innodb_log_file_in_groupを減らし、redoログの総量を小さくする事
で安定してSharp Checkpointが発生するようにする
(発生するioを平均的にしてしまう)
• innodb_log_file_in_group = 3(合計で3GB)
• 参考: これだけみれば大丈夫 Cacti によるMySQLパフォーマンス監視のツ
ボ (http://www.slideshare.net/nobuhatano/osc2015-my-sqlr3)
グラフで比較
5.6.26 ext4 5.6.26 *25.6.26 *1
5.6.26 ext4 5.6.26 *25.6.26 *1
5.6.26 ext4 5.6.26 *25.6.26 *1
• innodb_io_capacityが55000の場合、checkpoint-ageは張り付
かず、性能は安定。innodb_log_file_in_groupを変更した場合
はcheckpoint-ageは張り付くが性能は安定。
• 両ケースにおいて安定してpurgeが行わるためHistory Length
は伸びない
• 両ケース共に安定はしているが、innodb_io_capacityを増や
した方が高性能
• purge_invokedはどちらのパターンも増えているが、
innodb_log_file_in_groupを減らした方が高い位置で安定
• 5.6系でbuffer_flush_batch_num_scanが増えたらたぶん負け
5.6.26 ext4 5.6.26 *25.6.26 *1
performance_schemaからio待ちを見てみる
• ./storage/perfschema/pfs_instr.hより
/**
@def WAIT_STACK_LOGICAL_SIZE
Maximum number of nested waits.
Some waits, such as:
- "wait/io/table/sql/handler"
- "wait/lock/table/sql/handler"
are implemented by calling code in a storage engine,
that can cause nested waits (file io, mutex, ...)
Because of partitioned tables, a table io event (on the whole table)
can contain a nested table io event (on a partition).
Because of additional debug instrumentation,
waiting on what looks like a "mutex" (safe_mutex, innodb sync0sync, ...)
can cause nested waits to be recorded.
For example, a wait on innodb mutexes can lead to:
- wait/sync/mutex/innobase/some_mutex
- wait/sync/mutex/innobase/sync0sync
- wait/sync/mutex/innobase/os0sync
The max depth of the event stack must be sufficient
for these low level details to be visible.
*/
• WaitedTime/secにおいてwait/io/table/sql/handlerが性能劣化
時から増加していることからテーブルの操作(INSERTや
UPDATE)に時間がかかるようになっていると考えられます
5.6系+ext4の簡単なまとめ
• 高速なフラッシュストレージ、5.6系且つext4をデータ領域と
して使用している環境で更新処理が非常に多い時に性能が不
安定になる場合はinnodb_io_capacityを見直した方が良い可
能性がある
• 今回はLinkBenchのワークロードにおいて上手く動いてく
れただけなので、可能性でしかありません
• redoログのサイズ変更はMySQLの再起動が必要になるため
、オンライン変更が可能なinnodb_io_capacityの方がカジュ
アルに変更して効果が確認可能な点がメリットです
5.6系の場合
可能ならxfsを
使いましょう
おまけ: 5.6と5.7での違い
• Waits/secは大きな差が無い事から待ち回数の差は小
• Time/secが小さい事から同じ処理でも待ち時間が5.7の方が小さ
い
5.7.8 xfs 5.7.8 ext4 5.6.26 ext45.6.26 xfs
sxlock is 何?
• https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_rw_lock よ
り
• An sx-lock provides write access to a common resource
while permitting inconsistent reads by other threads. sx-
locks were introduced in MySQL 5.7 to optimize
concurrency and improve scalability for read-write workloads.
余談1
• MySQL 5.6系のinnodb_io_capacityの制御はかなり適当なので注
意が必要。普通はinnodb_io_capacityを極端に大きくしない方が
良いです
• ベンチマーク終了後に5.7系は一定のwrite量なのに5.6系は無茶苦
茶writeしていることからその事が良くわかります
5.7.8 xfs 5.7.8 ext4 5.6.26 ext45.6.26 xfs
ベンチ終了直後のsar -b
• 5.6
• 02:16:49 AM 69062.50 0.00 69062.50 0.00 1084890.91
• 02:16:50 AM 67874.16 0.00 67874.16 0.00 1067200.00
• 02:16:51 AM 69042.05 0.00 69042.05 0.00 1085245.45
• 5.7
• 03:06:25 AM 18944.33 0.00 18944.33 0.00 298795.88
• 03:06:26 AM 18871.43 0.00 18871.43 0.00 296669.39
• 03:06:27 AM 19266.67 0.00 19266.67 0.00 302866.67
5.7.8でパラメータによる
挙動の差を見てみる
対象パラメータ
• innodb_buffer_pool_instances
• innodb_lru_scan_depth
• innodb_io_capacity
• innodb_io_capacity_max
• innodb_page_cleaners
• 続いてグラフを見ていきますが、1のケースがスコアとして
は低いですが最も性能が安定しているように見えます。
• 2,3,4はやや性能がぶれる事がある
• 5は割と安定気味だけどinnodb_buffer_poolが埋まったタイミ
ングでの劣化がやや大きい
1 2 3 4 5
innodb_buffer_pool_instances 12
innodb_lru_scan_depth 1500
innodb_io_capacity 22000
innodb_io_capacity_max 25000
innodb_page_cleaners 8
Linkbenchスコア
• innodb_buffer_pool_instances
• InnoDBのバッファプールを指定した数で分割し、バッフ
ァの競合を削減します。
• innodb_lru_scan_depth
• マニュアルより: page_cleanerスレッドがフラッシュするダーティーページを
検索する際に、どのくらいの深さまでバッファープール LRU リストをスキャ
ンするのかが指定されます。これは、1 秒ごとに 1 回実行されるバックグラウ
ンド操作です。
• 動きとしては各バッファプールインスタンスのFree Buffer
が指定している値を下回っていたら指定した値まで空き領
域を確保しようとします
• よって最大で
Free Buffer = innodb_buffer_pool_instances x
innodb_lru_scan_depth
までバッファを開放しようとします。
• innodb_lru_scan_depthは増やした方が安定する事があるが、
Free Bufferが増える、つまり使用可能なバッファプールが減
るので増やしすぎるとioが増え、結果として性能が下がる場
合もあります。
• 指定した値が大きすぎるとその値までFree Bufferを確保しよ
うとするのでその待ち時間により劣化する場合もあります
innodb_buffer_pool_instancesが多い方がcheckpoint-ageは低い
山になり、innodb_io_capacityが多い方が5.6系と同様に低い山
になりました
innodb_buffer_pool_instancesを12にした真ん中3つはバッファ
プールが埋まったタイミングで書き込みが跳ね、一時的に性能
が劣化し、buffer_LRU_single_flush_num_scanが落ちたタイミ
ングで安定しています
• 性能が劣化したタイミングではwait/io/table/sql/handlerの待ちの回数
(Waits/sec)が減少しているが待ち時間(WaitTime/sec)が増えていること
からio待ちが発生している
• バッファプールからのinnodb_lru_scan_depthだけフラッシュする操作
による待ちと考えられます
まとめ
• dimSTATを使用するとperformance_schemaや
innodb_monitorから性能に関わる項目もグラフ化する事が可
能
• 性能測定の間隔が空いても間の時間は省略したグラフが作成
されるため比較がしやすくなります
• 取得される項目が大量のため見繕うのが大変ですが
Bookmarkの機能を利用して予め用意しておけばベンチ後に
気楽に値を参照可能となります
• 比較した内容はSnapshotにしておくと後からの参照が楽です
• 取得される項目が多いため、パラメータ変更の挙動を調べる
のに向いています
おわり
おまけ
ext4が何故遅いのか調べてみました
fio + perf + Flame Graphs
• 実行コマンド
• perf record -a -g -F100000 /usr/bin/fio --name=‘test’ 
--readwrite=randwrite --blocksize=4k --size=32m 
--filename=/var/lib/mysql/fio/fiotest --direct=1 --numjobs=16 
--group_reporting
• 1つのファイルに対して16プロセスでそれぞれ32MBの書き込み
をO_DIRECTで行います
• Flame Graphsの作成
• perf script > perf_data.txt
• stackcollapse-perf.pl perf_data.txt | flamegraph.pl --title “[タイ
トル名]” > [ファイル名].svg
• 参考: perf + Flame Graphs で Linux カーネル内のボトルネックを特定する
(http://d.hatena.ne.jp/yohei-a/20150706/1436208007)
細かすぎて見にくいので矢印のsystem_call_fastpathの部分を
クリックして拡大します
まだ見にくいので矢印の場所を拡大します
mutex_spin_on_ownerで時間がかかっている事が分かります
xfsの場合
細かすぎて見にくいので同様に矢印のsystem_call_fastpathの
部分をクリックして拡大します
ext4と違って山の高いところで横に長い処理
(mutex_spin_on_owner)がなく、どの処理もスムーズに動作し
ている事が分かります
(そもそもxfsがext4のようにmutex_lock取るのか知りませんが… それっぽいのは_spin_lock_irqsaveぐらい?)
fioのスコア(iops)
ext4 xfs
• ちなみに以下の様にdirectory指定でそれぞれのスレッドが異
なるファイルにwriteを行った場合はext4, xfsの両方とも十分
なiopsが出ます
• /usr/bin/fio --name='test' --readwrite=randwrite 
--blocksize=4k --size=100m 
--directory=/var/lib/mysql/fiotest --direct=1 
--numjobs=32 --loops=3 --group_reporting
ワークロードに適した
ファイルシステムを
選択しましょう
おまけのおわり

More Related Content

What's hot

MySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLはMySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLはyoku0825
 
MySQL 4.0で9年動き続けたサーバを リプレイスしてバージョンアップした話
MySQL 4.0で9年動き続けたサーバを リプレイスしてバージョンアップした話MySQL 4.0で9年動き続けたサーバを リプレイスしてバージョンアップした話
MySQL 4.0で9年動き続けたサーバを リプレイスしてバージョンアップした話Takahiro Okumura
 
Art of MySQL Replication.
Art of MySQL Replication.Art of MySQL Replication.
Art of MySQL Replication.Mikiya Okuno
 
What's New in MySQL 5.7 InnoDB
What's New in MySQL 5.7 InnoDBWhat's New in MySQL 5.7 InnoDB
What's New in MySQL 5.7 InnoDBMikiya Okuno
 
MHAの次を目指す mikasafabric for MySQL
MHAの次を目指す mikasafabric for MySQLMHAの次を目指す mikasafabric for MySQL
MHAの次を目指す mikasafabric for MySQLyoku0825
 
MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06
MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06
MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06Mikiya Okuno
 
dbts2013:MariaDB Galera Cluster 活用例
dbts2013:MariaDB Galera Cluster 活用例dbts2013:MariaDB Galera Cluster 活用例
dbts2013:MariaDB Galera Cluster 活用例Jun Shimizu
 
MySQL clients
MySQL clientsMySQL clients
MySQL clientsyoku0825
 
20160929 inno db_fts_jp
20160929 inno db_fts_jp20160929 inno db_fts_jp
20160929 inno db_fts_jpyoyamasaki
 
MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話Yoshinori Matsunobu
 
MySQL Clusterのトラブル事例
MySQL Clusterのトラブル事例MySQL Clusterのトラブル事例
MySQL Clusterのトラブル事例hiroi10
 
MySQL 5.6新機能解説@dbtechshowcase2012
MySQL 5.6新機能解説@dbtechshowcase2012MySQL 5.6新機能解説@dbtechshowcase2012
MySQL 5.6新機能解説@dbtechshowcase2012Mikiya Okuno
 
Handlersocket 20140218
Handlersocket 20140218Handlersocket 20140218
Handlersocket 20140218akirahiguchi
 
MySQL 5.7 InnoDB 日本語全文検索(その2)
MySQL 5.7 InnoDB 日本語全文検索(その2)MySQL 5.7 InnoDB 日本語全文検索(その2)
MySQL 5.7 InnoDB 日本語全文検索(その2)yoyamasaki
 
最近始めたあなたも今日から語れるようになるMySQLの{概要と最新情報}入門@
最近始めたあなたも今日から語れるようになるMySQLの{概要と最新情報}入門@最近始めたあなたも今日から語れるようになるMySQLの{概要と最新情報}入門@
最近始めたあなたも今日から語れるようになるMySQLの{概要と最新情報}入門@sakaik
 
What's New in MySQL 5.7 Security
What's New in MySQL 5.7 SecurityWhat's New in MySQL 5.7 Security
What's New in MySQL 5.7 SecurityMikiya Okuno
 

What's hot (17)

MySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLはMySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLは
 
MySQL 4.0で9年動き続けたサーバを リプレイスしてバージョンアップした話
MySQL 4.0で9年動き続けたサーバを リプレイスしてバージョンアップした話MySQL 4.0で9年動き続けたサーバを リプレイスしてバージョンアップした話
MySQL 4.0で9年動き続けたサーバを リプレイスしてバージョンアップした話
 
Art of MySQL Replication.
Art of MySQL Replication.Art of MySQL Replication.
Art of MySQL Replication.
 
What's New in MySQL 5.7 InnoDB
What's New in MySQL 5.7 InnoDBWhat's New in MySQL 5.7 InnoDB
What's New in MySQL 5.7 InnoDB
 
MySQLの冗長化 2013-01-24
MySQLの冗長化 2013-01-24MySQLの冗長化 2013-01-24
MySQLの冗長化 2013-01-24
 
MHAの次を目指す mikasafabric for MySQL
MHAの次を目指す mikasafabric for MySQLMHAの次を目指す mikasafabric for MySQL
MHAの次を目指す mikasafabric for MySQL
 
MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06
MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06
MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06
 
dbts2013:MariaDB Galera Cluster 活用例
dbts2013:MariaDB Galera Cluster 活用例dbts2013:MariaDB Galera Cluster 活用例
dbts2013:MariaDB Galera Cluster 活用例
 
MySQL clients
MySQL clientsMySQL clients
MySQL clients
 
20160929 inno db_fts_jp
20160929 inno db_fts_jp20160929 inno db_fts_jp
20160929 inno db_fts_jp
 
MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話
 
MySQL Clusterのトラブル事例
MySQL Clusterのトラブル事例MySQL Clusterのトラブル事例
MySQL Clusterのトラブル事例
 
MySQL 5.6新機能解説@dbtechshowcase2012
MySQL 5.6新機能解説@dbtechshowcase2012MySQL 5.6新機能解説@dbtechshowcase2012
MySQL 5.6新機能解説@dbtechshowcase2012
 
Handlersocket 20140218
Handlersocket 20140218Handlersocket 20140218
Handlersocket 20140218
 
MySQL 5.7 InnoDB 日本語全文検索(その2)
MySQL 5.7 InnoDB 日本語全文検索(その2)MySQL 5.7 InnoDB 日本語全文検索(その2)
MySQL 5.7 InnoDB 日本語全文検索(その2)
 
最近始めたあなたも今日から語れるようになるMySQLの{概要と最新情報}入門@
最近始めたあなたも今日から語れるようになるMySQLの{概要と最新情報}入門@最近始めたあなたも今日から語れるようになるMySQLの{概要と最新情報}入門@
最近始めたあなたも今日から語れるようになるMySQLの{概要と最新情報}入門@
 
What's New in MySQL 5.7 Security
What's New in MySQL 5.7 SecurityWhat's New in MySQL 5.7 Security
What's New in MySQL 5.7 Security
 

Similar to dimSTATから見るベンチマーク

MySQL最新情報 ※2015年9月5日「第1回 関西DB勉強会」での発表資料
MySQL最新情報 ※2015年9月5日「第1回 関西DB勉強会」での発表資料MySQL最新情報 ※2015年9月5日「第1回 関西DB勉強会」での発表資料
MySQL最新情報 ※2015年9月5日「第1回 関西DB勉強会」での発表資料yoyamasaki
 
20150131 ChugokuDB-Shimane-MySQL
20150131 ChugokuDB-Shimane-MySQL20150131 ChugokuDB-Shimane-MySQL
20150131 ChugokuDB-Shimane-MySQLRyusuke Kajiyama
 
PostgreSQLのトラブルシューティング@第5回中国地方DB勉強会
PostgreSQLのトラブルシューティング@第5回中国地方DB勉強会PostgreSQLのトラブルシューティング@第5回中国地方DB勉強会
PostgreSQLのトラブルシューティング@第5回中国地方DB勉強会Shigeru Hanada
 
MySQL 5.7 Technical Update (日本語)
MySQL 5.7 Technical Update (日本語)MySQL 5.7 Technical Update (日本語)
MySQL 5.7 Technical Update (日本語)Shinya Sugiyama
 
Sql database managed instance overview and internals
Sql database managed instance overview and internalsSql database managed instance overview and internals
Sql database managed instance overview and internalsMasayuki Ozawa
 
MySQLのNoSQL機能 - MySQL JSON & HTTP Plugin for MySQL
MySQLのNoSQL機能 - MySQL JSON & HTTP Plugin for MySQLMySQLのNoSQL機能 - MySQL JSON & HTTP Plugin for MySQL
MySQLのNoSQL機能 - MySQL JSON & HTTP Plugin for MySQLRyusuke Kajiyama
 
MySQL SYSスキーマのご紹介
MySQL SYSスキーマのご紹介MySQL SYSスキーマのご紹介
MySQL SYSスキーマのご紹介Shinya Sugiyama
 
States of Dolphin - MySQL最新技術情報2013秋 -
States of Dolphin - MySQL最新技術情報2013秋 -States of Dolphin - MySQL最新技術情報2013秋 -
States of Dolphin - MySQL最新技術情報2013秋 -yoyamasaki
 
20150920 中国地方db勉強会
20150920 中国地方db勉強会20150920 中国地方db勉強会
20150920 中国地方db勉強会yoyamasaki
 
Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)
Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)
Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)Colin Charles
 
What's new in open shift container platform 4.7 japan_20210318
What's new in open shift container platform 4.7 japan_20210318What's new in open shift container platform 4.7 japan_20210318
What's new in open shift container platform 4.7 japan_20210318Yuhki Hanada
 
Windows エンジニア向け sql server on linux のためのスキルアップデート
Windows エンジニア向け sql server on linux のためのスキルアップデートWindows エンジニア向け sql server on linux のためのスキルアップデート
Windows エンジニア向け sql server on linux のためのスキルアップデートMasayuki Ozawa
 
JBoss AS7 rev3
JBoss AS7 rev3JBoss AS7 rev3
JBoss AS7 rev3nekop
 
MySQL 初めてのチューニング
MySQL 初めてのチューニングMySQL 初めてのチューニング
MySQL 初めてのチューニングCraft works
 
企業におけるSpring@日本springユーザー会20090624
企業におけるSpring@日本springユーザー会20090624企業におけるSpring@日本springユーザー会20090624
企業におけるSpring@日本springユーザー会20090624Yusuke Suzuki
 
ISUCONの勝ち方 YAPC::Asia Tokyo 2015
ISUCONの勝ち方 YAPC::Asia Tokyo 2015ISUCONの勝ち方 YAPC::Asia Tokyo 2015
ISUCONの勝ち方 YAPC::Asia Tokyo 2015Masahiro Nagano
 
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Yoshinori Matsunobu
 
LINEのMySQL運用について
LINEのMySQL運用についてLINEのMySQL運用について
LINEのMySQL運用についてLINE Corporation
 
MySQL 5.7 & 最新開発状況 @ オープンソースカンファレンス20
MySQL 5.7 & 最新開発状況 @ オープンソースカンファレンス20MySQL 5.7 & 最新開発状況 @ オープンソースカンファレンス20
MySQL 5.7 & 最新開発状況 @ オープンソースカンファレンス20Ryusuke Kajiyama
 

Similar to dimSTATから見るベンチマーク (20)

PostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラPostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラ
 
MySQL最新情報 ※2015年9月5日「第1回 関西DB勉強会」での発表資料
MySQL最新情報 ※2015年9月5日「第1回 関西DB勉強会」での発表資料MySQL最新情報 ※2015年9月5日「第1回 関西DB勉強会」での発表資料
MySQL最新情報 ※2015年9月5日「第1回 関西DB勉強会」での発表資料
 
20150131 ChugokuDB-Shimane-MySQL
20150131 ChugokuDB-Shimane-MySQL20150131 ChugokuDB-Shimane-MySQL
20150131 ChugokuDB-Shimane-MySQL
 
PostgreSQLのトラブルシューティング@第5回中国地方DB勉強会
PostgreSQLのトラブルシューティング@第5回中国地方DB勉強会PostgreSQLのトラブルシューティング@第5回中国地方DB勉強会
PostgreSQLのトラブルシューティング@第5回中国地方DB勉強会
 
MySQL 5.7 Technical Update (日本語)
MySQL 5.7 Technical Update (日本語)MySQL 5.7 Technical Update (日本語)
MySQL 5.7 Technical Update (日本語)
 
Sql database managed instance overview and internals
Sql database managed instance overview and internalsSql database managed instance overview and internals
Sql database managed instance overview and internals
 
MySQLのNoSQL機能 - MySQL JSON & HTTP Plugin for MySQL
MySQLのNoSQL機能 - MySQL JSON & HTTP Plugin for MySQLMySQLのNoSQL機能 - MySQL JSON & HTTP Plugin for MySQL
MySQLのNoSQL機能 - MySQL JSON & HTTP Plugin for MySQL
 
MySQL SYSスキーマのご紹介
MySQL SYSスキーマのご紹介MySQL SYSスキーマのご紹介
MySQL SYSスキーマのご紹介
 
States of Dolphin - MySQL最新技術情報2013秋 -
States of Dolphin - MySQL最新技術情報2013秋 -States of Dolphin - MySQL最新技術情報2013秋 -
States of Dolphin - MySQL最新技術情報2013秋 -
 
20150920 中国地方db勉強会
20150920 中国地方db勉強会20150920 中国地方db勉強会
20150920 中国地方db勉強会
 
Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)
Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)
Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)
 
What's new in open shift container platform 4.7 japan_20210318
What's new in open shift container platform 4.7 japan_20210318What's new in open shift container platform 4.7 japan_20210318
What's new in open shift container platform 4.7 japan_20210318
 
Windows エンジニア向け sql server on linux のためのスキルアップデート
Windows エンジニア向け sql server on linux のためのスキルアップデートWindows エンジニア向け sql server on linux のためのスキルアップデート
Windows エンジニア向け sql server on linux のためのスキルアップデート
 
JBoss AS7 rev3
JBoss AS7 rev3JBoss AS7 rev3
JBoss AS7 rev3
 
MySQL 初めてのチューニング
MySQL 初めてのチューニングMySQL 初めてのチューニング
MySQL 初めてのチューニング
 
企業におけるSpring@日本springユーザー会20090624
企業におけるSpring@日本springユーザー会20090624企業におけるSpring@日本springユーザー会20090624
企業におけるSpring@日本springユーザー会20090624
 
ISUCONの勝ち方 YAPC::Asia Tokyo 2015
ISUCONの勝ち方 YAPC::Asia Tokyo 2015ISUCONの勝ち方 YAPC::Asia Tokyo 2015
ISUCONの勝ち方 YAPC::Asia Tokyo 2015
 
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)
 
LINEのMySQL運用について
LINEのMySQL運用についてLINEのMySQL運用について
LINEのMySQL運用について
 
MySQL 5.7 & 最新開発状況 @ オープンソースカンファレンス20
MySQL 5.7 & 最新開発状況 @ オープンソースカンファレンス20MySQL 5.7 & 最新開発状況 @ オープンソースカンファレンス20
MySQL 5.7 & 最新開発状況 @ オープンソースカンファレンス20
 

dimSTATから見るベンチマーク