MySQLメインの人がPostgreSQLのベンチマークをしてみた話

MySQLメインの人がPostgreSQLのベンチマークをしてみた話

1. 1. MySQLメインの人が PostgreSQLの ベンチマークをしてみた話 第2回 MySQL・PostgreSQLユーザグループ(MyNA・JPUG) 合同DB勉強会 2016/02/20
2. 2. 自己紹介 • いとう ひろゆき • サーバ運用・保守が仕事 • MySQL好き、酒好き
3. 3. 方向性 • 高負荷が続いても安定した性能が出るパラメ ータ設定を探す • そのため、瞬間的で良いから最大性能を出そ うとする場合は異なるパラメータになると考 えられます
4. 4. 謝辞 • PostgreSQLのパラメータやビューについて教 えて頂いたsoudaiさん、kkidaさん、 nuko.yokohamaさん、PostgresSQL Slackの方 々、有難うございました
5. 5. 環境
6. 6. • PostgreSQL 9.5.0 • File System • ext4(nobarrier,discard) • ベンチマークソフト • LinkBench • https://github.com/mdcallag/linkbench
7. 7. LinkBenchの補足1 • 元々はFacebookがMySQL向けに作成したベン チマークソフト(I/Oヘビー) • Facebookの中の人であるMark Callaghan宛に PostgreSQL対応のプルリクがあり、マージさ れたため試してみました
8. 8. LinkBenchの補足2 • 微妙にバグがあり、LinkStorePgsql.javaを修 正しています(データロードしてもnodetableが 空になるため) • なおFacebookのgithubのLinkBenchにはマー ジされていないはずです
9. 9. LinkBenchの補足3 • 同じようなクエリではあるけどテーブル定義 とか微妙にMySQLと異なっていたりします
10. 10. ベンチマーク環境 • HP DL360 G8v2 • Intel Xeon E5-2643 v2 3.50GHz x 2 (2P12C24T) • MEM 8GB x 8 = 64GB • ioDrive2 785G (Driver version: 3.2.6) • NIC Intel I350 • CentOS 6.6(2.6.32-504.12.2.el6.x86_64)
11. 11. postgresql.conf • shared_buffers = 16GB • work_mem = 16MB • bgwriter_delay = 10ms • wal_level = archive • wal_sync_method = open_datasync • wal_buffers = 32MB • wal_max_size = 16GB
12. 12. • checkpoint_timeout = 60min • checkpoint_completion_target = 0.9 • archive_mode = on • archive_command = 'test ! -f /var/lib/pgsql/linkdb/archivedir/%f && pigz < %p > /var/lib/pgsql/linkdb/archivedir/%f’ • effective_cache_size = 4GB • log_checkpoints = on • autovaccum = off
13. 13. LinkBenchのオプション • FBWorkload.properties にてmaxid1 = 20000001 • pg_xlogを除いて約36GB • 実行コマンド(試験中) • /bin/linkbench -c config/LinkConfigPgsql.properties -D maxtime=600 -D requests=10000000 -D requesters=64 -r • maxtimeはパラメータが固まったら3600(1時間)
14. 14. 初期から変更した設定1 • max_wal_sizeの変更(1GB -> 16GB) • HINT: Consider increasing the configuration parameter “max_wal_size”. • 8GBも試したが今回の環境では1割ちょっと16GBの方が 高スコア • archive_commandの圧縮をgzipからpigzへ変更 • pg_xlog以下が40GB超えたりしたので
15. 15. 初期から変更した設定2 • shared_buffers (40GB -> 16GB) • データ量に対してshared_buffersが十分に大きいと background writer(bgwriter)が仕事をしないため • LinkBenchのようにI/O負荷が高いベンチマークでは チェックポイントの際の書き込み負荷が高く、 bgwriterにより少しずつで良いから吐き出してもらう ため
16. 16. 不安定なI/O状況 • 取得間隔は15秒 • 定期的に書き込みが跳ねる • 頑張ってもLinkBenchのスコアは36000前後をふらふら
17. 17. 多少安定させる事に成功
18. 18. 割と安定した時のI/O状況 • 取得間隔は15秒 • checkpointの際に書き込みが跳ねるが割と安定 • LinkBenchのスコアは38000前後に向上
19. 19. 割と安定させた設定 • PostgreSQLの設定ではなくOSの設定 • sysctl.conf • vm.dirty_background_bytes = 33554432 • vm.dirty_bytes = 268435456
20. 20. • 以下設定でもデフォルトと比較するとマシ • vm.dirty_ratio = 3 • vm.dirty_background_ratio = 1 • いくらbgwriterが頑張ってもメモリのダーティペー ジ(/proc/meminfoのDirty)を吐き出す処理が重い • ダーティページのメモリに対する割合を小さくし 、積極的に書き出させることで瞬間的な書き込み 量を削減(SSDに優しく無い)
21. 21. • dstat --top-io --top-bioで以下のようにダーティペ ージの書き出しががっつり来てる事が確認できま す • postgres: a 112M 47M|flush-252:0 0 509M • PostgreSQLのSlackでKernel 3.2以降だと I/O less dirty throttlingが使えるとのことなので環 境違いますがCentOS7.2で同じベンチマークを実 施
22. 22. ベンチマーク環境2 • 自作サーバ • Intel Xeon E5-2630 2.30GHz x 2 (2P12C24T) • MEM 8GB x 8 = 64GB • Intel SSD 910 Series 400GB (200GB x 2, RAID0(md0), ext4) • NIC Intel I350 • CentOS 7.2
23. 23. 環境違い過ぎるので参考まで • dstatで経過を見ているとメモリのダーティページ の書き出しが最も高い書き込み量となることはあ りませんでした • 環境や設定次第ですがCentOS7系やKernel3.2系 の機能が入ってるOSを使うだけでメモリのダー ティページのフラッシュによるスローダウンが減 少するかもしれません
24. 24. 話しを戻して
25. 25. まだ何か出来ないか？ • とにかく書き込みが多い(300MB/s前後とか) • 読み取りは一定時間経過すればメモリに収まるので block readはほとんど発生しなくなる • パラメータ何か無いかSHOW ALL;を眺める • wal_compressionを見つける • 圧縮なのでCPUの負荷は上がるだろうけど、まだ余裕があり そうなので試してみた
26. 26. 書き込み状況 • 書き込み量が最大でも200MBちょっとに減少 • 10分間で4回発生していたチェックポイントが 2回に減少し、スコアも40057に上昇
27. 27. 比較のために wal_compression off/on で1時間実行
28. 28. 結果
29. 29. OFF 33657
30. 30. ON 39152
31. 31. wal_compressionの効果 • OFFの場合、時間と共に性能が落ちていく • ONの場合、性能は同様に落ちていく傾向にあ るが、減少幅が非常に小さい
32. 32. 推測 • PCI-E SSDのように高速なI/Oデバイスを使用してお り、そのI/Oデバイスが主に書き込みにより限界近く で動いている場合、wal_compressionは有効に働く と考えられる • HDDの場合もI/O負荷が高い場合はCPUが余る傾向に なるはずなので、効果はあると考えられるがI/O負荷 が低い環境では性能劣化に繋がると考えられる
33. 33. グラフから 考察
34. 34. 左wal_compression off, 右on
35. 35. さて
36. 36. ここまでは autovacuum OFF
37. 37. ということで autovacuum ON
38. 38. 結果
39. 39. 38004
40. 40. あまり 性能低下 しなかった
41. 41. 改めて グラフ
42. 42. 左autovacuum off, 右on
43. 43. autovacuum off/on • グラフからは明確な差は確認出来ないレベル となりました • wal_compressionを有効にした事でI/Oについ てはある程度余裕が出来ていたためvacuumに よるI/Oが増えても影響が軽微で済んだと考え られます
44. 44. MySQLユーザから見て • 開発方針の違いとはいえOSの影響をここまで受けるとは思わなかった • MySQLではメモリのダーティページは最近のバージョンを利用して いる場合、増えることは基本無いため • 高負荷が続くことの多いソーシャルゲームでMySQLが利用される事が 多いのは高負荷が続く場合に安定させるのが大変というのも理由なの かな、と感じた • 適材適所ですよね。とはいえこのぐらいの性能出るならほとんどの サービスで問題の無い処理時間で動作すると思います
45. 45. • チェックポイントの書き込み量はもっと細く 制御出来ると良さそう • 一定の負荷が続く場合、このぐらい書き込 み一定にして性能を安定させたい
46. 46. 今後 • 今回はメモリに収まる範囲のデータ量でベン チマークを行ったので、MySQLでも行ってる ように200GBぐらいのデータ量でも安定する か測定してみたい
47. 47. ここから 追加スライド
48. 48. 質問で • transparent huge pages(THP)は無効ですか？ • に対して私が勘違いして無効と答えてて、懇 親会で間違いに気づいて追加でベンチを取っ たりした内容になります。
49. 49. 結果
50. 50. 38465 THP never wal_compression on autovaccum on
51. 51. やや落ちたけど 色々コマンド発行し てたから誤差程度 かと思います
52. 52. THPが悪さしているのか • 分からないのかなー、と色々教えてもらった り調べたりしていたら割とperfと FrameGraphsで分かりそうなのでTHP always, neverのそれぞれ1時間のベンチマーク を実行 • 1分毎にperfで元データ収集しました
53. 53. perfの取得方法 • perf record -a -g -F 99 -o [ファイル] sleep 10 • 1ファイル2.5M前後 • 終わったとのFrameGraphsにしました
54. 54. THP alwaysの30分後の FlameGraphs
55. 55. THP neverの30分後の FlameGraphs
56. 56. 見た感じ • postmaster(PostgreSQL)のpglz_compress(た ぶんwal_compressionの処理)や archive_commandで指定したpigzに時間がか かるのは仕方無い • THP alwaysだとJava(LinkBench)側に 平らな場所があって怪しいので拡大してみる
57. 57. THP alwaysのJavaの所を拡大
58. 58. THP neverのJavaの所を拡大
59. 59. ということで • Java(LinkBench)についてはTHP alwaysでは page_faultからの積み上げでcompactionがいて THPの影響をそれなりに受けていたようです • postmaster(PostgreSQL)は今回のケースに おいてはTHPの影響は軽微という結果になりま した
60. 60. とはいえ • 今回はデータ量がメモリに収まる程度でした ので100GB単位のデータ量にすると傾向が変 わったり、ワークロードによっても傾向が変 わるかもしれません • きちんとそれぞれの環境で計測しましょう
61. 61. 厳密に比較するなら • LinkBench(Java)自体が割とTHPの影響を受け てしまうので別のサーバからネットワーク越 しに負荷をかける必要がある • 繰り返しになりますがFrameGraphsを見る限 りは今回PostgreSQLに与える影響は少なそう なので大きな差は出ないと考えられます