Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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...
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=‘%s...
デモ
dimSTATから見る
ベンチマーク
ベンチマーク環境
• HP DL360p G8v2 (ベンチマークサーバ)
• CPU Intel Xeon E5-2643 v2 @ 3.50GHz x 2(1CPU =
6Core)
• MEM 8GB x 8 = 64GB
• ioDri...
• HP DL360 G7(ベンチマーククライアント)
• CPU Intel Xeon L5640 @ 2.27GHz (2CPU = 6Core x 2)
• MEM 4GB x 12 = 48GB
• NIC Broadcom NetXt...
• MySQL バージョン(RPM版使用)
• 5.7.8 RC 及び 5.6.26
• ベンチマークツール
• LinkBench
• データ量 218GB
FBWorkload.propertiesでmaxid1 = 200000001
•...
計測内容
1. 基本MySQLは同じ設定
未設定によるデフォルトは対象バージョン準拠
2. MySQL 5.7, 5.6それぞれでxfs, ext4でベンチマークを実施
3. LinkBenchの条件はリクエスト数のみ指定
✦ ./bin/li...
ポイントとなるパラメータ
• innodb_io_capacity = 18000
• innodb_io_capacity_max = 23000
• innodb_log_file_size = 1G
• innodb_log_files_...
ベンチマーク結果
• 5.6.26より5.7.8の方がxfs, ext4どちらでも高スコア
• 同一バージョンでの比較ではxfsの方が高スコア
• 5.6.26(ext4)が何故遅いのかdimSTAT等から見ていきます。*1,
*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 = 1...
• 5.6.26 ext4の性能劣化が発生したタイミングからほぼほぼ
purge_invokedが増えていないため、これを改善出来れば性
能が改善されると考えられる。History Lengthも増えてるい
る事からも安定して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_invoke...
2パターンの対応
1. innodb_io_capacity, innodb_io_capacity_maxを極端に増やしてみる
• innodb_io_capacity = 55000
• innodb_io_capacity_max = 6...
グラフで比較
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は張り付くが性能は安定。
• 両ケ...
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:...
5.6系+ext4の簡単なまとめ
• 高速なフラッシュストレージ、5.6系且つext4をデータ領域と
して使用している環境で更新処理が非常に多い時に性能が不
安定になる場合は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...
sxlock is 何?
• https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_rw_lock よ
り
• An sx-lock provides write access t...
余談1
• MySQL 5.6系のinnodb_io_capacityの制御はかなり適当なので注
意が必要。普通はinnodb_io_capacityを極端に大きくしない方が
良いです
• ベンチマーク終了後に5.7系は一定のwrite量なのに...
ベンチ終了直後の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 106720...
5.7.8でパラメータによる
挙動の差を見てみる
対象パラメータ
• innodb_buffer_pool_instances
• innodb_lru_scan_depth
• innodb_io_capacity
• innodb_io_capacity_max
• innodb_page...
• 続いてグラフを見ていきますが、1のケースがスコアとして
は低いですが最も性能が安定しているように見えます。
• 2,3,4はやや性能がぶれる事がある
• 5は割と安定気味だけどinnodb_buffer_poolが埋まったタイミ
ングでの劣...
• innodb_buffer_pool_instances
• InnoDBのバッファプールを指定した数で分割し、バッフ
ァの競合を削減します。
• innodb_lru_scan_depth
• マニュアルより: page_cleanerス...
• innodb_lru_scan_depthは増やした方が安定する事があるが、
Free Bufferが増える、つまり使用可能なバッファプールが減
るので増やしすぎるとioが増え、結果として性能が下がる場
合もあります。
• 指定した値が大き...
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待ちが発生している
• バッファプールからのin...
まとめ
• dimSTATを使用するとperformance_schemaや
innodb_monitorから性能に関わる項目もグラフ化する事が可
能
• 性能測定の間隔が空いても間の時間は省略したグラフが作成
されるため比較がしやすくなります
• 取...
おわり
おまけ
ext4が何故遅いのか調べてみました
fio + perf + Flame Graphs
• 実行コマンド
• perf record -a -g -F100000 /usr/bin/fio --name=‘test’ 
--readwrite=randwrite --blocks...
細かすぎて見にくいので矢印のsystem_call_fastpathの部分を
クリックして拡大します
まだ見にくいので矢印の場所を拡大します
mutex_spin_on_ownerで時間がかかっている事が分かります
xfsの場合
細かすぎて見にくいので同様に矢印のsystem_call_fastpathの
部分をクリックして拡大します
ext4と違って山の高いところで横に長い処理
(mutex_spin_on_owner)がなく、どの処理もスムーズに動作し
ている事が分かります
(そもそもxfsがext4のようにmutex_lock取るのか知りませんが… それっぽいのは_sp...
fioのスコア(iops)
ext4 xfs
• ちなみに以下の様にdirectory指定でそれぞれのスレッドが異
なるファイルにwriteを行った場合はext4, xfsの両方とも十分
なiopsが出ます
• /usr/bin/fio --n...
ワークロードに適した
ファイルシステムを
選択しましょう
おまけのおわり
dimSTATから見るベンチマーク
Upcoming SlideShare
Loading in …5
×

dimSTATから見るベンチマーク

14,249 views

Published on

MyNA会(2015年8月)

Published in: Technology
  • Be the first to comment

  • Be the first to like this

dimSTATから見るベンチマーク

  1. 1. dimSTATから見る ベンチマーク MyNA会(2015年8月)
  2. 2. 自己紹介 • いとう ひろゆき • サーバ運用/保守が仕事 • ネットワークからOS、ミドルウェアまでアプリケーション 以外は何でも面倒を見ます(程度の差はあります) • MySQL好き、酒好き
  3. 3. @kamipoさん、 Oracle Aceおめでとうございます
  4. 4. お題 • dimSTATって何? • dimSTATの簡単な使い方 • dimSTATのグラフを見てみる • dimSTATから見るベンチマーク
  5. 5. dimSTATって何? • MySQLに関するブログを書かれているDimitriさん作成のモニ タリングツール(http://dimitrik.free.fr) • こんなグラフ見た事ありませんか?
  6. 6. • 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)
  7. 7. dimSTATの 簡単な使い方
  8. 8. dimSTATのグラフを見てみる
  9. 9. 1台の場合、そのまま Analyze をクリック
  10. 10. 1. Hostの横のチェックボックスを選択 2. 見たいグラフの項目をクリック
  11. 11. 項目を全部表示するために”More>>>”をクリック
  12. 12. 大量に出て来た中から wait/synch/* の大きい方から10件のグ ラフを描画します
  13. 13. • 上位10件のみ表示するため Select TOP-[10]にチェック • 絞り込みたいパターンとして wait/synch/* を入力し Use Select Pattern にチェック
  14. 14. グラフ描画する条件を選択します。 今回は LOG Messages で範囲を指定しています。
  15. 15. Waits/sec を表示するため、Values の所にチェックを入れて Go! をクリック
  16. 16. • 以上が基本的な操作 • Time/sec をチェックした場合は待ち時間が長いTOP10がグ ラフ描画されます
  17. 17. dimSTATの簡単な使い方 1. インストール 2. 取得したいサーバの登録 3. 取得開始 4. ベンチマークとか実行 5. 停止 6. グラフを見る(取得中も可)
  18. 18. dimSTAT利用時の設定 • my.cnfに以下設定を行う事が推奨となります • performance_schema = ON (5.6, 5.7ならデフォルトでON) • performance_schema_instrument=‘%sync%=on' • innodb_monitor_enable = 'all'
  19. 19. デモ
  20. 20. dimSTATから見る ベンチマーク
  21. 21. ベンチマーク環境 • 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)
  22. 22. • 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)
  23. 23. • MySQL バージョン(RPM版使用) • 5.7.8 RC 及び 5.6.26 • ベンチマークツール • LinkBench • データ量 218GB FBWorkload.propertiesでmaxid1 = 200000001 • ファイルシステム • xfs, ext4 マウントオプション: defaults,nobarrier,discard
  24. 24. 計測内容 1. 基本MySQLは同じ設定 未設定によるデフォルトは対象バージョン準拠 2. MySQL 5.7, 5.6それぞれでxfs, ext4でベンチマークを実施 3. LinkBenchの条件はリクエスト数のみ指定 ✦ ./bin/linkbench -c config/MyConfig.properties -D requests=600000 -r ✦ リクエスト数のデフォルト値は1000000 ✦ スレッド数のデフォルトは100
  25. 25. ポイントとなるパラメータ • 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)
  26. 26. ベンチマーク結果 • 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)
  27. 27. 同一設定のグラフ 5.7.8 xfs 5.7.8 ext4 5.6.26 ext45.6.26 xfs
  28. 28. • 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
  29. 29. • 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状況
  30. 30. バッファのフラッシュ状況 • buffer_flush_batch_num_scanと buffer_LRU_search_scannedがやたらと増加している 5.7.8 xfs 5.7.8 ext4 5.6.26 ext45.6.26 xfs
  31. 31. • ./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
  32. 32. 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)
  33. 33. グラフで比較 5.6.26 ext4 5.6.26 *25.6.26 *1
  34. 34. 5.6.26 ext4 5.6.26 *25.6.26 *1
  35. 35. 5.6.26 ext4 5.6.26 *25.6.26 *1
  36. 36. • 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が増えたらたぶん負け
  37. 37. 5.6.26 ext4 5.6.26 *25.6.26 *1 performance_schemaからio待ちを見てみる
  38. 38. • ./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)に時間がかかるようになっていると考えられます
  39. 39. 5.6系+ext4の簡単なまとめ • 高速なフラッシュストレージ、5.6系且つext4をデータ領域と して使用している環境で更新処理が非常に多い時に性能が不 安定になる場合はinnodb_io_capacityを見直した方が良い可 能性がある • 今回はLinkBenchのワークロードにおいて上手く動いてく れただけなので、可能性でしかありません • redoログのサイズ変更はMySQLの再起動が必要になるため 、オンライン変更が可能なinnodb_io_capacityの方がカジュ アルに変更して効果が確認可能な点がメリットです
  40. 40. 5.6系の場合 可能ならxfsを 使いましょう
  41. 41. おまけ: 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
  42. 42. 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.
  43. 43. 余談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
  44. 44. ベンチ終了直後の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
  45. 45. 5.7.8でパラメータによる 挙動の差を見てみる
  46. 46. 対象パラメータ • innodb_buffer_pool_instances • innodb_lru_scan_depth • innodb_io_capacity • innodb_io_capacity_max • innodb_page_cleaners
  47. 47. • 続いてグラフを見ていきますが、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スコア
  48. 48. • 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 までバッファを開放しようとします。
  49. 49. • innodb_lru_scan_depthは増やした方が安定する事があるが、 Free Bufferが増える、つまり使用可能なバッファプールが減 るので増やしすぎるとioが増え、結果として性能が下がる場 合もあります。 • 指定した値が大きすぎるとその値までFree Bufferを確保しよ うとするのでその待ち時間により劣化する場合もあります
  50. 50. innodb_buffer_pool_instancesが多い方がcheckpoint-ageは低い 山になり、innodb_io_capacityが多い方が5.6系と同様に低い山 になりました
  51. 51. innodb_buffer_pool_instancesを12にした真ん中3つはバッファ プールが埋まったタイミングで書き込みが跳ね、一時的に性能 が劣化し、buffer_LRU_single_flush_num_scanが落ちたタイミ ングで安定しています
  52. 52. • 性能が劣化したタイミングではwait/io/table/sql/handlerの待ちの回数 (Waits/sec)が減少しているが待ち時間(WaitTime/sec)が増えていること からio待ちが発生している • バッファプールからのinnodb_lru_scan_depthだけフラッシュする操作 による待ちと考えられます
  53. 53. まとめ
  54. 54. • dimSTATを使用するとperformance_schemaや innodb_monitorから性能に関わる項目もグラフ化する事が可 能 • 性能測定の間隔が空いても間の時間は省略したグラフが作成 されるため比較がしやすくなります • 取得される項目が大量のため見繕うのが大変ですが Bookmarkの機能を利用して予め用意しておけばベンチ後に 気楽に値を参照可能となります • 比較した内容はSnapshotにしておくと後からの参照が楽です • 取得される項目が多いため、パラメータ変更の挙動を調べる のに向いています
  55. 55. おわり
  56. 56. おまけ ext4が何故遅いのか調べてみました
  57. 57. 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)
  58. 58. 細かすぎて見にくいので矢印のsystem_call_fastpathの部分を クリックして拡大します
  59. 59. まだ見にくいので矢印の場所を拡大します
  60. 60. mutex_spin_on_ownerで時間がかかっている事が分かります
  61. 61. xfsの場合
  62. 62. 細かすぎて見にくいので同様に矢印のsystem_call_fastpathの 部分をクリックして拡大します
  63. 63. ext4と違って山の高いところで横に長い処理 (mutex_spin_on_owner)がなく、どの処理もスムーズに動作し ている事が分かります (そもそもxfsがext4のようにmutex_lock取るのか知りませんが… それっぽいのは_spin_lock_irqsaveぐらい?)
  64. 64. 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
  65. 65. ワークロードに適した ファイルシステムを 選択しましょう
  66. 66. おまけのおわり

×