![perfの取得方法
• perf record -a -g -F 99 -o [ファイル] sleep 10
• 1ファイル2.5M前後
• 終わったとのFrameGraphsにしました](https://image.slidesharecdn.com/myna-jpugpostgresql20160222-160226071326/85/MySQL-PostgreSQL-59-320.jpg)
MySQLメインの人がPostgreSQLのベンチマークをしてみた話
- 2. 自己紹介 • いとう ひろゆき • サーバ運用・保守が仕事 • MySQL好き、酒好き
- 5. 環境
- 6. • PostgreSQL 9.5.0 • File System • ext4(nobarrier,discard) • ベンチマークソフト • LinkBench • https://github.com/mdcallag/linkbench
- 7. LinkBenchの補足1 • 元々はFacebookがMySQL向けに作成したベン チマークソフト(I/Oヘビー) • Facebookの中の人であるMark Callaghan宛に PostgreSQL対応のプルリクがあり、マージさ れたため試してみました
- 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. 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. • 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. 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. 初期から変更した設定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. 初期から変更した設定2 • shared_buffers (40GB -> 16GB) • データ量に対してshared_buffersが十分に大きいと background writer(bgwriter)が仕事をしないため • LinkBenchのようにI/O負荷が高いベンチマークでは チェックポイントの際の書き込み負荷が高く、 bgwriterにより少しずつで良いから吐き出してもらう ため
- 16. 不安定なI/O状況 • 取得間隔は15秒 • 定期的に書き込みが跳ねる • 頑張ってもLinkBenchのスコアは36000前後をふらふら
- 17. 多少安定させる事に成功
- 18. 割と安定した時のI/O状況 • 取得間隔は15秒 • checkpointの際に書き込みが跳ねるが割と安定 • LinkBenchのスコアは38000前後に向上
- 19. 割と安定させた設定 • PostgreSQLの設定ではなくOSの設定 • sysctl.conf • vm.dirty_background_bytes = 33554432 • vm.dirty_bytes = 268435456
- 20. • 以下設定でもデフォルトと比較するとマシ • vm.dirty_ratio = 3 • vm.dirty_background_ratio = 1 • いくらbgwriterが頑張ってもメモリのダーティペー ジ(/proc/meminfoのDirty)を吐き出す処理が重い • ダーティページのメモリに対する割合を小さくし 、積極的に書き出させることで瞬間的な書き込み 量を削減(SSDに優しく無い)
- 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. ベンチマーク環境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
- 24. 話しを戻して
- 25. まだ何か出来ないか？ • とにかく書き込みが多い(300MB/s前後とか) • 読み取りは一定時間経過すればメモリに収まるので block readはほとんど発生しなくなる • パラメータ何か無いかSHOW ALL;を眺める • wal_compressionを見つける • 圧縮なのでCPUの負荷は上がるだろうけど、まだ余裕があり そうなので試してみた
- 28. 結果
- 29. OFF 33657
- 30. ON 39152
- 32. 推測 • PCI-E SSDのように高速なI/Oデバイスを使用してお り、そのI/Oデバイスが主に書き込みにより限界近く で動いている場合、wal_compressionは有効に働く と考えられる • HDDの場合もI/O負荷が高い場合はCPUが余る傾向に なるはずなので、効果はあると考えられるがI/O負荷 が低い環境では性能劣化に繋がると考えられる
- 33. グラフから 考察
- 38. さて
- 41. 結果
- 42. 38004
- 43. あまり 性能低下 しなかった
- 44. 改めて グラフ
- 49. autovacuum off/on • グラフからは明確な差は確認出来ないレベル となりました • wal_compressionを有効にした事でI/Oについ てはある程度余裕が出来ていたためvacuumに よるI/Oが増えても影響が軽微で済んだと考え られます
- 50. MySQLユーザから見て • 開発方針の違いとはいえOSの影響をここまで受けるとは思わなかった • MySQLではメモリのダーティページは最近のバージョンを利用して いる場合、増えることは基本無いため • 高負荷が続くことの多いソーシャルゲームでMySQLが利用される事が 多いのは高負荷が続く場合に安定させるのが大変というのも理由なの かな、と感じた • 適材適所ですよね。とはいえこのぐらいの性能出るならほとんどの サービスで問題の無い処理時間で動作すると思います
- 53. ここから 追加スライド
- 54. 質問で • transparent huge pages(THP)は無効ですか？ • に対して私が勘違いして無効と答えてて、懇 親会で間違いに気づいて追加でベンチを取っ たりした内容になります。
- 55. 結果
- 58. THPが悪さしているのか • 分からないのかなー、と色々教えてもらった り調べたりしていたら割とperfと FrameGraphsで分かりそうなのでTHP always, neverのそれぞれ1時間のベンチマーク を実行 • 1分毎にperfで元データ収集しました
- 59. perfの取得方法 • perf record -a -g -F 99 -o [ファイル] sleep 10 • 1ファイル2.5M前後 • 終わったとのFrameGraphsにしました
- 62. 見た感じ • postmaster(PostgreSQL)のpglz_compress(た ぶんwal_compressionの処理)や archive_commandで指定したpigzに時間がか かるのは仕方無い • THP alwaysだとJava(LinkBench)側に 平らな場所があって怪しいので拡大してみる
- 65. ということで • Java(LinkBench)についてはTHP alwaysでは page_faultからの積み上げでcompactionがいて THPの影響をそれなりに受けていたようです • postmaster(PostgreSQL)は今回のケースに おいてはTHPの影響は軽微という結果になりま した