不揮発WALバッファ
•
1 like•1,123 views
2020年5月21日に開催された第13回PostgreSQLアンカンファレンスでの発表資料です。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 不揮発WALバッファ
Similar to 不揮発WALバッファ (20)
More from NTT Software Innovation Center
More from NTT Software Innovation Center (20)
不揮発WALバッファ
- 1. 不揮発 WAL バッファ 2020/05/21 // 第13回 PostgreSQL アンカンファレンス 毛受 崇 (NTT ソフトウェアイノベーションセンタ)
- 2. • 名前・所属・連絡先 – 毛受 崇 (めんじょう たかし) – NTT ソフトウェアイノベーションセンタ – takashi.menjou.vg@hco.ntt.co.jp • お仕事 – 以前：分散ブロックストレージの研究開発 (Sheepdog) – 現在：PMEM (後述) を活用するソフトウェア技術の研究開発 • PostgreSQL 歴３年 – 2017年：PostgreSQL Conference Japan 2017 – 2018年：PGCon 2018 2 自己紹介
- 5. • DIMM スロットに挿して使う不揮発なメモリ – 電源断の前後で内容が保持される – CPU がバイト単位でロード・ストアできる – ディスクと比べて高速でランダムアクセスに強い – 既に製品も出ている • NVDIMM-N 規格のもの (同容量の DRAM と NAND Flash を搭載) • Intel Optane DC Persistent Memory Module (DCPMM) (3D XPoint 技術を 使用しており、記憶素子自体が永続性を持つ) • プログラミングパラダイムの変革 – 「永続的なデバイスはメモリと比べて遅い」という前提が崩れる – メモリにアクセスするようにデータを永続化する利用技術が必要 5 Persistent memory (PMEM)
- 6. • Filesystem DAX – OS とファイルシステムの機能 • Linux では今のところ ext2, ext4, xfs がサポート – 実データの読み書き時にページキャッシュをバイパスする • メタデータの読み書きは従来と同様にページキャッシュを経由する – アプリケーションの変更なく PMEM を高速に利用できる • Persistent Memory Development Kit (PMDK) – ユーザ空間ライブラリ • Intel 主導で OSS として開発が進んでいる† – Filesystem DAX 上のメモリマップドファイルに対する操作を提供する – 実データの読み書きはカーネルをバイパスしてさらに高速になるが、 アプリケーションの変更が必要 6 PMEM を高速に使うための技術 † https://pmem.io/pmdk/
- 7. 7 PMEM を高速に使うための技術 (続き) PMEM メモリマップド ファイル ：ユーザ実データの流れ 「メモリのように」使う アプリケーション ページキャッシュ ブロックデバイス PMDK ファイルシステム ファイルシステム (DAX) ユ ー ザ 空 間 カ ー ネ ル 空 間 ペナルティ！ ペナルティ！ read/write システムコール read/write システムコール メモリコピー HDDやSSDなどと同じように使う
- 8. • PGCon 2018 では I/O 処理に PMDK を適用した – 対象は WAL と Relation – open と read/write をメモリマップとメモリコピーに置換え – DRAM と PMEM に同じデータが重複 • その後、PG の設計に踏み込んだ適用を検討してきた – DRAM 上のデータ構造を PMEM 上に置いて操作できないか 8 PGCon 2018 とその後 不揮発 WAL バッファ (Non-volatile WAL buffer)
- 9. • PMEM 上に置いた WAL バッファで永続化を完結させる – セグメントファイルへの出力は原則として行わない – バッファは十分に大きなサイズとする (数GB～) • コピー回数が２回から１回に減り、性能改善が期待できる 9 不揮発 WAL バッファ DRAM 共有バッファ PMEM 表 索引 WAL バッファ セグ メント PMEM にコピー Ｄ Ｒ Ａ Ｍ に コ ピ ー DRAM 共有バッファ PMEM 表 索引 不揮発 WAL バッファ Ｐ Ｍ Ｅ Ｍ に コ ピ ー
- 10. • PGCon 2016 で堀川隆さんが発表された Non-volatile Memory Logging[1] 版の PostgreSQL[2] をベースとした – PMEM を模擬する特別なカーネルモジュールあり – PMEM 上の WAL バッファ (～80MB) へコピー後、ディスクへ非同期に書出し • DAX Filesystem と PMDK を使用して実装した – カーネルモジュールの代わりに、Filesystem DAX 上の指定ファイルを不揮発 WAL バッファとしてメモリマップ – コミット、チェックポイント、クラッシュリカバリの処理を改造 • WAL セグメントファイルを使う機能の互換性はなるべく維持している – クラッシュリカバリ – WAL アーカイブと PITR (タイムラインIDの処理はまだ怪しい…) – (ストリーミングレプリケーションは現在対応中…) 10 実装 [1] https://www.pgcon.org/2016/schedule/track/Performance/945.en.html [2] https://github.com/meistervonperf/postgresql-NVM-logging
- 11. 性能測定 11
- 12. • 不揮発 WAL バッファの性能優位性を評価する • 比較対象は既存の PostgreSQL とする – 無改造の PostgreSQL に加えて、PGCon 2018 で発表した改造のパッ チを適用したものも含む • PMEM として NVDIMM-N と Intel DCPM を用いる – 注意：各 PMEM の搭載マシンは別々である • pgbench のスループットおよび平均レイテンシを指標とする – 全てのテーブルに対して、測定前に pg_prewarm を実施 – クライアントの並列度を変化させて測定 (接続数 c, スレッド数 j) – 30分×3回測定してスループットが中央値となった回の結果を採用 性能測定 – 概要 12
- 13. 名称 PostgreSQL の改造 WAL の 永続化 WAL を永続化 するデバイスと ファイルシステム 補足説明 Original なし する PMEM + ext4 DAX ベースライン PGCon 2018 PGCon 2018 版*1 する PMEM + ext4 DAX Non-volatile WAL buffer 不揮発 WAL バッファ*2 する PMEM + ext4 DAX UNLOGGED + async なし しない*3 PMEM + ext4 DAX 性能限界の 参考値 13 性能測定 – 比較対象 *1: https://www.postgresql.org/message-id/C20D38E97BCB33DAD59E3A1@lab.ntt.co.jp *2: https://www.postgresql.org/message-id/002f01d5d28d$23c01430$6b403c90$@hco.ntt.co.jp_1 *3: UNLOGGED テーブルと非同期コミットを使用
- 14. postgres PMEM PCIe SSD 14 性能測定 – 構成 pgbench WAL Seg. Shared buffer WAL buffer Relation postgres PMEM PCIe SSD WAL Seg. Shared buffer WAL buffer Relation postgres PMEM PCIe SSD Shared buffer Relation WAL buffer NV WAL (mmap) (mmap) write memcpy memcpy memcpy memcpy pgbench pgbench Original ※ PGCon 2018 Non-volatile WAL buffer NUMAノード1 NUMAノード0 ※ "UNLOGGED + async" の構成は "Original (PMEM)" と同じだが、WAL の永続化有無が異なる。 ２ソケットで 2 NUMA ノード のマシン１台を 使用し、一方の ノードでサーバ を、他方でクラ イアントを稼働。 ノードあたり18 コア。WALと Relationの保存 先には別々のデ バイスを使用。 HW/SW スペッ クとコンフィグ は巻末に。
- 15. 15 性能測定 – 結果 (NVDIMM-N)
- 16. 16 性能測定 – 結果 (DCPMM)
- 17. 性能解析 17
- 18. • 不揮発 WAL バッファの効果のあらわれ方を明らかにする – 特に、WAL の複製回数を削減した効果を確認する • サーバプロセスの CPU 時間を関数ごとに解析する – 解析には VTune を用いる – 並列度は (c, j)=(36,18) とする • 関数の中でも WAL の処理に注目する – XLogInsert (WALバッファへのレコードのメモリコピー) – XLogFlush (WALの永続化) • pgbench で定量または定時の負荷をかける – 定量：各クライアントが 67,500 トランザクションを実行 (t=67,500) – 定時：実時間で30秒間実行 (T=30) 18 性能解析 – 概要
- 19. 19 性能解析 – NVDIMM-N・定量 (1/3)
- 20. 20 性能解析 – NVDIMM-N・定量 (2/3)
- 21. 21 性能解析 – NVDIMM-N・定量 (3/3)
- 23. 23 性能解析 – DCPMM・定量 (1/3)
- 24. 24 性能解析 – DCPMM・定量 (2/3)
- 25. 25 性能解析 – DCPMM・定量 (3/3)
- 27. • スループットとレイテンシの両方を改善した – 性能限界の参考値 (UNLOGGED + async) に近づいた • WAL 処理時間の短縮により、レイテンシを改善した – セグメントファイルへの書出しを削減 – 書出しにともなうロック処理も削減 • クエリ読込みの時間が増え、スループットが改善した – これまで WAL 処理に要していた時間を充てられるようになった • ホットスポットが WAL 処理以外に移りつつある？ 27 結果と考察
- 28. • パッチの使い方 – まずはパッチに含まれる README を読んでみてください – 実物の PMEM がなくても DRAM でエミュレーションできます • パッチの internal 28 今日話せなかったこと (またの機会に話したいこと)
- 29. 測定環境 29
- 30. Item Value System HPE ProLiant DL380 Gen10 CPU Intel Xeon Gold 6154 x2 sockets DRAM DDR4 2666MHz 192GiB†/socket x2 sockets NVDIMM-N DDR4 2666MHz 96GiB‡/socket x2 sockets Optane SSD DC P4800X Series SSDPED1K750GA 30 Hardware (NVDIMM-N server) † 32 GB/channel x 6 channels/socket ‡ 16 GB/channel x 6 channels/socket; interleaving enabled
- 31. Item Value System HPE ProLiant DL380 Gen10 CPU Intel Xeon Gold 6240M x2 sockets DRAM DDR4 2933MHz 192GiB†/socket x2 sockets DCPMM DDR4 2666MHz 1.5TiB‡/socket x2 sockets Optane SSD DC P4800X Series SSDPED1K750GA 31 Hardware (DCPMM server) † 32 GB/channel x 6 channels/socket ‡ 256 GB/channel x 6 channels/socket; interleaving enabled
- 32. 32 Software Item Value Distro Ubuntu 18.04 C compiler gcc 7.4.0 libc glibc 2.27 Linux kernel 5.4 (vanilla) PMDK 1.7 PostgreSQL 12.0 (refs/tags/REL_12_0) VTune 2019 Update 6 (build 602217)
- 33. Item Value max_connections 300 shared_buffers 32GB checkpoint_timeout 12min checkpoint_completion_target 0.7 {max,min}_wal_size 80GB random_page_cost 1.0 effective_cache_size 96GB autovacuum_max_workers 4 autovacuum_freeze_max_age 2000000000 (2×109) autovauum_vacuum_cost_limit 400 Scale factor (pgbench -i -s ...) 1000 Database connection Unix domain socket Query mode (pgbench -M ...) prepared 33 Common PostgreSQL configuration
- 34. wal_sync_ method synchronous_ commit Use UNLOGGED table (pgbench –i --unlogged-tables) Original fdatasync on No PGCon 2018 pmem_drain on No Non-volatile WAL buffer fdatasync on No UNLOGGED + async fdatasync off Yes 34 Specific PostgreSQL configuration