第2回 MySQL・PostgreSQLユーザグループ(MyNA・JPUG)
合同DB勉強会で使用したスライドと追加が含まれています

1. MySQLメインの人が
PostgreSQLの
ベンチマークをしてみた話
第2回 MySQL・PostgreSQLユーザグループ(MyNA・JPUG)
合同DB勉強会
2016/02/20

2. 自己紹介
• いとう ひろゆき
• サーバ運用・保守が仕事
• MySQL好き、酒好き

3. 方向性
• 高負荷が続いても安定した性能が出るパラメ
ータ設定を探す
• そのため、瞬間的で良いから最大性能を出そ
うとする場合は異なるパラメータになると考
えられます

4. 謝辞
• PostgreSQLのパラメータやビューについて教
えて頂いたsoudaiさん、kkidaさん、
nuko.yokohamaさん、PostgresSQL Slackの方
々、有難うございました

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対応のプルリクがあり、マージさ
れたため試してみました

8. LinkBenchの補足2
• 微妙にバグがあり、LinkStorePgsql.javaを修
正しています(データロードしてもnodetableが
空になるため)
• なおFacebookのgithubのLinkBenchにはマー
ジされていないはずです

9. LinkBenchの補足3
• 同じようなクエリではあるけどテーブル定義
とか微妙にMySQLと異なっていたりします

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

23. 環境違い過ぎるので参考まで
• dstatで経過を見ているとメモリのダーティページ
の書き出しが最も高い書き込み量となることはあ
りませんでした
• 環境や設定次第ですがCentOS7系やKernel3.2系
の機能が入ってるOSを使うだけでメモリのダー
ティページのフラッシュによるスローダウンが減
少するかもしれません

24. 話しを戻して

25. まだ何か出来ないか？
• とにかく書き込みが多い(300MB/s前後とか)
• 読み取りは一定時間経過すればメモリに収まるので
block readはほとんど発生しなくなる
• パラメータ何か無いかSHOW ALL;を眺める
• wal_compressionを見つける
• 圧縮なのでCPUの負荷は上がるだろうけど、まだ余裕があり
そうなので試してみた

26. 書き込み状況
• 書き込み量が最大でも200MBちょっとに減少
• 10分間で4回発生していたチェックポイントが
2回に減少し、スコアも40057に上昇

27. 比較のために
wal_compression off/on
で1時間実行

28. 結果

29. OFF
33657

30. ON
39152

31. wal_compressionの効果
• OFFの場合、時間と共に性能が落ちていく
• ONの場合、性能は同様に落ちていく傾向にあ
るが、減少幅が非常に小さい

32. 推測
• PCI-E SSDのように高速なI/Oデバイスを使用してお
り、そのI/Oデバイスが主に書き込みにより限界近く
で動いている場合、wal_compressionは有効に働く
と考えられる
• HDDの場合もI/O負荷が高い場合はCPUが余る傾向に
なるはずなので、効果はあると考えられるがI/O負荷
が低い環境では性能劣化に繋がると考えられる

33. グラフから
考察

34. 左wal_compression off, 右on

38. さて

39. ここまでは
autovacuum
OFF

40. ということで
autovacuum
ON

41. 結果

42. 38004

43. あまり
性能低下
しなかった

44. 改めて
グラフ

45. 左autovacuum off, 右on

49. autovacuum off/on
• グラフからは明確な差は確認出来ないレベル
となりました
• wal_compressionを有効にした事でI/Oについ
てはある程度余裕が出来ていたためvacuumに
よるI/Oが増えても影響が軽微で済んだと考え
られます

50. MySQLユーザから見て
• 開発方針の違いとはいえOSの影響をここまで受けるとは思わなかった
• MySQLではメモリのダーティページは最近のバージョンを利用して
いる場合、増えることは基本無いため
• 高負荷が続くことの多いソーシャルゲームでMySQLが利用される事が
多いのは高負荷が続く場合に安定させるのが大変というのも理由なの
かな、と感じた
• 適材適所ですよね。とはいえこのぐらいの性能出るならほとんどの
サービスで問題の無い処理時間で動作すると思います

51. • チェックポイントの書き込み量はもっと細く
制御出来ると良さそう
• 一定の負荷が続く場合、このぐらい書き込
み一定にして性能を安定させたい

52. 今後
• 今回はメモリに収まる範囲のデータ量でベン
チマークを行ったので、MySQLでも行ってる
ように200GBぐらいのデータ量でも安定する
か測定してみたい

53. ここから
追加スライド

54. 質問で
• transparent huge pages(THP)は無効ですか？
• に対して私が勘違いして無効と答えてて、懇
親会で間違いに気づいて追加でベンチを取っ
たりした内容になります。

55. 結果

56. 38465
THP never
wal_compression on
autovaccum on

57. やや落ちたけど
色々コマンド発行し
てたから誤差程度
かと思います

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にしました

60. THP alwaysの30分後の
FlameGraphs

61. THP neverの30分後の
FlameGraphs

62. 見た感じ
• postmaster(PostgreSQL)のpglz_compress(た
ぶんwal_compressionの処理)や
archive_commandで指定したpigzに時間がか
かるのは仕方無い
• THP alwaysだとJava(LinkBench)側に
平らな場所があって怪しいので拡大してみる

63. THP alwaysのJavaの所を拡大

64. THP neverのJavaの所を拡大

65. ということで
• Java(LinkBench)についてはTHP alwaysでは
page_faultからの積み上げでcompactionがいて
THPの影響をそれなりに受けていたようです
• postmaster(PostgreSQL)は今回のケースに
おいてはTHPの影響は軽微という結果になりま
した

66. とはいえ
• 今回はデータ量がメモリに収まる程度でした
ので100GB単位のデータ量にすると傾向が変
わったり、ワークロードによっても傾向が変
わるかもしれません
• きちんとそれぞれの環境で計測しましょう

67. 厳密に比較するなら
• LinkBench(Java)自体が割とTHPの影響を受け
てしまうので別のサーバからネットワーク越
しに負荷をかける必要がある
• 繰り返しになりますがFrameGraphsを見る限
りは今回PostgreSQLに与える影響は少なそう
なので大きな差は出ないと考えられます