Successfully reported this slideshow.
Your SlideShare is downloading. ×

dimSTATから見るベンチマーク

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
MySQL5.6と5.7性能比較
MySQL5.6と5.7性能比較
Loading in …3
×

Check these out next

1 of 67 Ad

More Related Content

Slideshows for you (18)

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

Advertisement

Recently uploaded (20)

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. おまけのおわり

×