20221116_DBTS_PGStrom_History
0 likes151 views
2022/11/16のDB Tech Showcaseでの発表資料です。
![GPUとはどんなプロセッサか？（1/2）
多数のコアと広帯域メモリによる強力な並列演算性能を有する。
CPU
Cache
CUDA Core
CUDA Core
CUDA Core
CUDA Core
CUDA Core
CUDA Core
CUDA Core
CUDA Core
広帯域メモリ
GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～
7
Intel Xeon Platinum 8380
# of cores: 40
clock: 2.30GHz
3.40GHz (boost)
L1 cache: 64kB / core
L2 cache: 1MB / core
L3 cache: 60MB / proc
DRAM: DDR4-3200 x 8
(max 204.8GB/s)
NVIDIA A100 [80GB; PCI-E]
# of CUDA cores: 6,912 [32bit]
(108 SM)
clock: 1.065 GHz
1.410 GHz (boost)
L1 cache: 192kB / SM (*)
L2 cache: 40MB / proc
DRAM: HBM2e [80GB]
(max 1,935GB/s)](https://image.slidesharecdn.com/c-7heterodb20221102dbtspgstrom-221116093945-65368e84/85/20221116_DBTS_PGStrom_History-7-320.jpg)
![GPUとはどんなプロセッサか？（2/2）
GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～
8
スレッド同士での同期やデータ交換を低コストで実行できる
●
item[0]
step.1 step.2 step.4
step.3
GPUを用いた
Σi=0...N-1item[i]
配列総和の計算
◆
●
▲ ■ ★
● ◆
●
● ◆ ▲
●
● ◆
●
● ◆ ▲ ■
●
● ◆
●
● ◆ ▲
●
● ◆
●
item[1]
item[2]
item[3]
item[4]
item[5]
item[6]
item[7]
item[8]
item[9]
item[10]
item[11]
item[12]
item[13]
item[14]
item[15]
log2N ステップで
items[]の総和を計算
HW支援によるコア間の同期機構
SELECT count(X),
sum(Y),
avg(Z)
FROM my_table;
集約関数の計算で用いる仕組み](https://image.slidesharecdn.com/c-7heterodb20221102dbtspgstrom-221116093945-65368e84/85/20221116_DBTS_PGStrom_History-8-320.jpg)
20221116_DBTS_PGStrom_History
- 1. GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ HeteroDB,Inc Chief Architect & CEO KaiGai Kohei <kaigai@heterodb.com>
- 2. 自己紹介／会社紹介 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 2 会社概要 ? 商号 ヘテロDB株式会社 ? 創業 2017年7月4日 ? 拠点 品川区北品川5-5-15 大崎ブライトコア4F ? 事業内容 高速データ処理製品の開発?販売 GPU＆DB領域の技術コンサルティング ヘテロジニアスコンピューティング技術をデータベース領域に適用し、 誰もが使いやすく、シンプルで高速な大量データ分析基盤を提供する。 代表者プロフィール ? 海外 浩平（KaiGai Kohei） ? OSS開発者コミュニティにおいて、PostgreSQLやLinux kernelの 開発に15年以上従事。主にセキュリティ?FDW等の分野で PostgreSQLのメインライン機能の強化に貢献。 ? IPA未踏ソフト事業において“天才プログラマー”認定 (2006) ? GPU Technology Conference Japan 2017でInception Awardを受賞
- 4. GPU-DBの10年を振り返る（1/2） NVIDIA TESLA C2070 (2009) CUDA Cores: 448 (Fermi) DRAM: 6GB (GDDR5) PCI-E 2.0 x16, FP32: 1.03TFlops NVIDIA TESLA K20X (2012) CUDA Cores: 2,688 (Kepler) DRAM: 6GB (GDDR5) PCI-E 3.0 x16, FP32: 3.95TFlops NVIDIA TESLA P100 (2016) CUDA Cores: 3,584 (Pascal) DRAM: 16GB (HBM2) PCI-E 3.0 x16, FP32: 9.56TFlops NVIDIA TESLA V100 (2017) CUDA Cores: 5,120 (Volta) DRAM: 32GB (HBM2) PCI-E 3.0 x16, FP32: 14.0TFlops NVIDIA A100 (2020) CUDA Cores: 6,912 (Ampare) DRAM: 80GB (HBM2) PCI-E 4.0 x16, FP32: 19.5TFlops GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 4
- 5. GPU-DBの10年を振り返る（2/2） （2017～） PG-Strom （2012～） （2014～） （旧MAP-D; 2013～） （2016～） （2014～） （2015～） （2016～） ? 2010年頃 「ビッグデータ」が盛り上がる。Hadoopなど大人気。 ? GPUの性能?信頼性が向上を続け、DBMSへの組み込みも現実味。 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 5
- 7. GPUとはどんなプロセッサか？（1/2） 多数のコアと広帯域メモリによる強力な並列演算性能を有する。 CPU Cache CUDA Core CUDA Core CUDA Core CUDA Core CUDA Core CUDA Core CUDA Core CUDA Core 広帯域メモリ GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 7 Intel Xeon Platinum 8380 # of cores: 40 clock: 2.30GHz 3.40GHz (boost) L1 cache: 64kB / core L2 cache: 1MB / core L3 cache: 60MB / proc DRAM: DDR4-3200 x 8 (max 204.8GB/s) NVIDIA A100 [80GB; PCI-E] # of CUDA cores: 6,912 [32bit] (108 SM) clock: 1.065 GHz 1.410 GHz (boost) L1 cache: 192kB / SM (*) L2 cache: 40MB / proc DRAM: HBM2e [80GB] (max 1,935GB/s)
- 8. GPUとはどんなプロセッサか？（2/2） GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 8 スレッド同士での同期やデータ交換を低コストで実行できる ● item[0] step.1 step.2 step.4 step.3 GPUを用いた Σi=0...N-1item[i] 配列総和の計算 ◆ ● ▲ ■ ★ ● ◆ ● ● ◆ ▲ ● ● ◆ ● ● ◆ ▲ ■ ● ● ◆ ● ● ◆ ▲ ● ● ◆ ● item[1] item[2] item[3] item[4] item[5] item[6] item[7] item[8] item[9] item[10] item[11] item[12] item[13] item[14] item[15] log2N ステップで items[]の総和を計算 HW支援によるコア間の同期機構 SELECT count(X), sum(Y), avg(Z) FROM my_table; 集約関数の計算で用いる仕組み
- 9. PostgreSQLにGPUを試そうとしたきっかけ ▌PGconf 2011 (Ottawa) で聴講したあるセッション??? ? Parallel Image Searching Using PostgreSQL and PgOpenCL Running PostgreSQL Stored Procedures on a GPU ? https://www.pgcon.org/2011/schedule/events/352.en.html ? 画像処理用のストアドプロシジャを、GPU用のプログラミング環境 OpenCL で作成するための拡張モジュールについて。 A列 B列 C列 D列 E列 幅の小さいデータでも、 大量の行を並べれば 長大なBLOBと同じく GPU並列処理が効くのでは？ May-2011 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 9
- 10. 実際に作ってみた（1/2） FDWを使用して、テーブル構造の裏側に 簡易的な列ストアを作成した。 ※ 当時はFDWが唯一のエグゼキュータを 拡張するための方法。 CPUでテーブルをスキャンし、同時に、 並行してGPUで条件句を処理するという 構造を持っていた。 ※ 当時は並列クエリ実行が無かった Jan-2012 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 10
- 11. 実際に作ってみた（2/2） WHERE条件句から CUDA C のコードを 自動生成してJITコンパイルを行う。 ※ EXPLAINすると CUDA C の生のソース コードが表示される。かなりシュール。 Jan-2012 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 11
- 12. PostgreSQL v9.3における機能強化 Sep-2013 ← Background worker process 通常のPostgreSQLテーブルを、裏で列ストアに変換し ようと提案した機能。 ↓ Writable foreign tables 元々はPG-Strom用のFDWテーブルにINSERTや UPDATEを使ってデータをロードするため提案。 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 12
- 13. 「お仕事」として PG-Strom の開発に取り組む Dec-2013 『社内新事業公募』における審査 （※ イメージ） GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 13
- 14. 2014年のGPUを振り返る ▌優先すべき課題 ① クラッシュしない ② 正しい計算結果を返す ③ クラッシュしない ④ デバッグしやすい構造 ⑤ クラッシュしない ⑥ 高いパフォーマンス NVIDIA TESLA K20X ? 第３世代 Kepler アーキテクチャ ? 2,688個のCUDAコアと、6GiBのGDDR5 DRAMを搭載 ? PCI-E 3.0 x16レーンでホストシステムと接続 ? ECCメモリ搭載。エンタープライズ用途での利用も意識したモデル。 まずは DBMS 側の 品質を上げる！ 2014 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 14
- 15. 「趣味」から「実用」に向けたアーキテクチャの変更 ? OpenCL ? CUDAへの移行 ? マルチプラットフォーム（NVIDIA, AMD, Intel）? 再現できないトラブル報告が多数寄せられる（死 ? CUDA 7.0以降はNVRTCが提供される ? CUDAでもランタイムコンパイルが可能に ? 各バックエンドプロセス内でGPUを制御する方式に移行 ? CUDA Contextの生成に要する時間は許容可能なレベル（OpenCLの場合は数秒を要していた） ? エラーが発生したときのクラッシュダンプの採取しやすさ 新しいアーキテクチャ （CUDAベース） PostgreSQL Backend CUDA Context PG-Strom host/GPU code PostgreSQL Backend CUDA Context PG-Strom host/GPU code PostgreSQL Backend CUDA Context PG-Strom host/GPU code Postmaster Process fork(2) PostgreSQL Backend 従来のアーキテクチャ （OpenCLベース） PG-Strom host code PostgreSQL Backend Background Worker PG-Strom GPU Service Postmaster Process fork(2) PG-Strom host code Local connection to GPU Service Device Context 2014 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 15
- 16. PostgreSQL v9.5における機能強化 May-2015 Parser Optimizer Executor execBegin Exec execEnd CustomScan API PostgreSQL本体へのパッチを必要せず、純粋に 拡張モジュールのみでGPU実行を実装できるように。 SQL 実行結果 パース木 実行計画 add_scan_path add_join_path BeginCustomScan ExecCustomScan EndCustomScan 拡張モジュールによる実装 CustomScan API GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 16
- 17. 難儀な問題：GPUメモリの使用量予測 full table scan GpuScan GpuJoin 64MB SCAN系処理なら、必ず「入力データ量 ≧ 出力データ量」 JOIN系処理なら「入力データ量＜出力データ量」があり得る。 ? バッファの必要量をDB統計情報から予測するなど kernel source buffer kernel source buffer kernel result buffer kernel result buffer GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 17
- 18. Pascal世代GPUの登場 NVIDIA TESLA P100 ? 第５世代 Pascal アーキテクチャ ? 3,584個のCUDAコアと、16GiBのHBM2 DRAMを搭載 ? PCI-E 3.0 x16レーンでホストシステムと接続 ? FP64のアトミック演算に対応 ? GPUでのデマンドページングとメモリオーバーコミットに対応 Apr-2016 どういうことか？ ? GPUメモリの論理アドレス空間上で雑に malloc() しておけば、実際に使った分だけGPUメモリを 割り当てる。 ? GPUメモリが足りなければ、ホストメモリと スワッピングを行う。 ? 複雑＆不正確な結果バッファのサイズ推定と リトライから解放される事に。 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 18
- 19. Pascal世代GPUによるメモリ管理の簡略化 ▌第４世代 Maxwell 以前 JOINやGroup Byなど『事前に行数の最大値を 予測する』ことが難しいワークロードに対しても、 過不足なくメモリを割り当てる事が必要。 ? DBの統計情報を使ったりしていたが、 基本的に無理ゲーであった。 ▌第５世代 Pascal 以降 ある程度ざっくりと大きなメモリを割り当てても、 実際に使用した分だけしか物理メモリを消費しな いため、メモリ使用量の予測そのものが不要に。 ? バグの原因となる複雑なロジックそのものの 解消と、品質の改善に大きく寄与。 せっかく割り当てたメモリを 全然使っていなかった。 ? 同時に他のタスクを 動かせたはずなのに！ これだけあれば十分だと予測した けれども、実際には不足。 ? リトライでパフォーマンスが 低下してしまう…。 GPU物理メモリ GPU論理アドレス空間 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 19
- 20. SSD-to-GPU Direct SQLの着想と開発（1/3） 冬-2015 GPUコア GPU Device Memory CPU Host Memory ストレージ （HDD/SSD） CPU 720GB/s 16GB/s 0.5GB/s 60GB/s NVME-SSD 一台あたり 3GB/s （当時の）PG-Stromを含む、 GPU-DBはデータがオンメモリ前提 ストレージに落ちたら「負け」 一方この頃、NVME-SSD製品が登場 安価な高速SSDがブレイクの兆し。 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 20
- 21. SSD-to-GPU Direct SQLの着想と開発（2/3） 冬-2015 NVIDIA GPUDirect RDMA nvme.ko ドライバ nvme_strom.ko ドライバ ホストメモリ デバイスメモリ 物理アドレス空間 NVME-READ From: Block 1234 Qty: 32 Dest: 0x34567000 NVME-READ From: Block 2345 Qty: 32 Dest: 0x45678000 NVME コマンド NVME コマンド GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 21
- 22. SSD-to-GPU Direct SQLの着想と開発（3/3） ? GPU-Direct SQL（当時は SSD-to-GPU Direct SQL）により、メモリサイズを越えた 大量データ（数TB～）を処理する事が可能に。 ? この特徴が、PG-Stromが他のGPU-DB製品とは異なった進化をするきっかけに。 ? この頃は、猫も杓子も “Deep Learning!” “Deep Learning!” Aug-2016 実験用に購入した Intel SSD 750 (400GB) の 理論帯域まで出ている (!) GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 22
- 23. GTC-2017にて May-2017 NVIDIA TESLA V100 ? 第6世代 Volta アーキテクチャ ? 5,120個のCUDAコアと、最大32GiBのHBM2 DRAMを搭載 ? PCI-E 3.0 x16レーンでホストシステムと接続 ? Tensorコアを搭載した初めてのモデル （深層学習用の専用計算回路） ? 各スレッドがProgram Counterを持つ事になり、分岐処理を持つ ソフトウェアの実行がより高速に。 GPU Technology Conference 2017で発表した SSD-to-GPU Direct SQLのポスターは、全138件の中から Top-5 Finalistとして選出され、来場者投票で惜しくも次点に。 PCI-Eバスが更に高速化し、GPUの処理能力ですらも 飽和に近付くAmpare以降の世代で効いてくる特徴 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 23
- 24. HeteroDB社の設立 ▌製品コンセプトを再定義する ? PostgreSQLを使い慣れた人はたくさんいる。 ? GPU-DB「だけど」計算ワークロードよりも I/O中心のバッチ系処理に強い。 ? IoT/M2Mなど、日々積み重なるものの、 更新処理がほとんどないデータが増加 ? ログデータの分析?検索用途に適した 「データ処理製品」として定義づけ。 Jul-2017 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 24
- 25. ① Apache Arrowへの対応（1/3） ETL OLTP OLAP 伝統的なOLTP&OLAPシステム － データはDBシステムの内側で生成される Data Creation IoT/M2M時代 － データはDBシステムの外側で生成される Log processing BI Tools BI Tools Gateway Server Data Creation Data Creation Many Devices GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 25 DBシステムへのデータのインポートが、集計処理以上に時間のかかる処理に！ Data Import Import! 2019
- 26. ① Apache Arrowへの対応（2/3） GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 26 ▌Arrow形式の特徴 ? 列指向で分析用途向けに設計されたデータ形式 ? アプリケーションによらず、共通のデータ交換形式として利用可能 ? 整数、実数、日付時刻、文字列など基本的なデータ型を定義 ? 更新?削除は無理だが、追記に強い（? ログデータに向いた形式） NVIDIA GPU PostgreSQL / PG-Strom 2019
- 27. ① Apache Arrowへの対応（3/3） GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 27 ▌なぜApache Arrow形式がログデータ処理に適しているのか？ ? 被参照列のみ読み出すため、I/O量が少なくて済む ? GPUメモリバスの特性から、プロセッサ実行効率が高い ? Read-onlyデータなので、実行時のMVCC検査を行う必要がない SSD-to-GPU Direct SQL機構を使って、被参照列だけを転送する。 PCIe Bus NVMe SSD GPU SSD-to-GPU P2P DMA WHERE-clause JOIN GROUP BY クエリの被参照列のみ、 ダイレクトデータ転送 Apache Arrow形式を解釈し、 データを取り出せるよう GPUコード側での対応。 小規模の処理結果だけを PostgreSQLデータ形式で返す Results metadata 2019
- 28. ② データ処理速度 10GB/s への挑戦（1/2） 複数SSD（md-raid0）への対応と、品質?安定性の改良 Supermicro 1019GP-TT CPU: Xeon Gold 6126T (2.6GHz, 12C) RAM: 192GB (32GB DDR4-2666 x6) GPU: NVIDIA Tesla P40 (3840C, 24GB) x1 SSD: Intel SSD DC P4600 (2.0TB, HHHL) x3 HDD: 2.0TB (SATA, 72krpm) x6 N/W: 10Gb ethernet x2ports 2018 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 28
- 29. PostgreSQL パーティション ② データ処理速度 10GB/s への挑戦（2/2） オプティマイザで頑張り、SSD-GPUから漏出するデータを減らす lineorder lineorder_p0 lineorder_p1 lineorder_p2 customer date supplier parts Scan Scan Scan Agg 実行結果 Scan Join Gather レコード数が多いと 結合処理が大変 2018 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 29
- 30. PostgreSQL パーティション ② データ処理速度 10GB/s への挑戦（2/2） オプティマイザで頑張り、SSD-GPUから漏出するデータを減らす lineorder lineorder_p0 lineorder_p1 lineorder_p2 customer date supplier parts Scan Scan Scan Gather Agg 実行結果 Scan Join PreAgg Join PreAgg Join PreAgg GROUP BYまでGPUで済ませると、 ほとんどのデータはホスト側に 戻ってこない。 2018 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 30
- 31. ～100TB程度の ログデータを シングルノードで 処理可能に ４ユニットの並列動作で、 100～120GB/sの 実効データ処理能力 列データ構造により ユニット毎25～30GB/sの 実効データ転送性能 秒速で10億レコードを処理する（1/2） QPI SSD-to-GPU Direct SQL、列志向ストア、PCIeバス最適化の全てを投入 CPU2 CPU1 RAM RAM PCIe-SW PCIe-SW NVME0 NVME1 NVME2 NVME3 NVME4 NVME5 NVME6 NVME7 NVME8 NVME9 NVME10 NVME11 NVME12 NVME13 NVME14 NVME15 GPU0 GPU1 GPU2 GPU3 HBA0 HBA1 HBA2 HBA3 GPU+4xSSDユニット あたり8.0～10GB/sの 物理データ転送性能 31 PCIe-SW PCIe-SW JBOF unit-0 JBOF unit-1 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ Oct-2019
- 32. 秒速で10億レコードを処理する（2/2） Oct-2019 Supermicro 4029GP-TRT CPU: Xeon Gold 6226 (2.7GHz, 12C) x2 RAM: 192GB (16GB DDR4-2666) x12 GPU: NVIDIA Tesla V100 (5120C, 16GB) x4 SSD: Intel SSD DC P4510 (1.0TB, U.2) x16 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 32
- 34. GTC-2020 (online) にて GPU Technology Conference 2020 基調講演より NVIDIA A100 ? 第8世代 Ampere アーキテクチャ ? 6,912個のCUDAコアと、最大80GiBのHBM2 DRAMを搭載 ? L2キャッシュサイズの拡大（V100の 6MB → 40MB） ? PCI-E 4.0 x16レーンでホストシステムと接続 長らく続いた PCI-E 3.0 世代からの切り替え。 GPU 1台あたり処理能力の目安は 20GB/s 強となり、 来たる PCI-E 5.0 世代では 40～50GB/s が見込まれる。 NVIDIA GPUDirect Storage May-2020 従来の自社製ドライバ（nvme_strom.ko）とほぼ 同等機能を有するソフトウェアスタックが、 NVIDIAよりCUDA Toolkitの標準機能のひとつとして 公式にリリースされると発表。 ? HeteroDB も事前評価に参加し、水面下で対応 作業を進めていた。 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 34
- 35. 次世代のPG-Stromで取り組むべきテーマ ? PCI-E 4.0 / 5.0 の帯域幅に対応できる実装 ? 同時接続数の増加に対応できるアーキテクチャ ? 省電力?低CO2排出（DPU対応） GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 35
- 36. GPU利用効率の改善（1/2） 非対称な処理を挟むとGPUのパフォーマンスは大きく劣化する ● ● ● ● ● ● ● ● ● ● LaneId: 0 1 2 3 4 27 28 29 30 31 Warp: unit of execution in GPU (32 simultaneous threads) 検索条件句の評価 F F F T F F F T F F 結果バッファの スロットを確保 被参照列を読み出し、 結果バッファへ追記 htup = LoadTupleFromSource(base_index+LaneId); rv = ExecEvalWhereClause(htup, whereClause); mask = __ballot_sync(__activemask(), rv); if (LaneId == 0) { count = __popc(mask); base = AllocateDestinationBuffer(count); } base = __shfl_sync(__activemask(), base, 0); if (rv) { mask &= ((1U << LaneId) - 1); dst_index = base + __popc(mask); ExecProjectionAndWriteBuffer(dst_index, htup, ProjectionList); } GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 36 2022
- 37. GPU利用効率の改善（2/2） PCI-E 3.0時代(12GB/s)はGPUの処理能力に余裕があったが、 PCI-E 5.0(50GB/s)になるとGPU側にもかなりの最適化が必要 Shared Counter 32レコードを 同時に読み出し WHERE条件句を 評価 ローカルバッファに 評価したレコードの ポインタを記録 ローカルバッファ内の レコード数 ≧ 32 F T ローカルバッファから 32レコードを 同時に読み出し 結果バッファに 32レコード分の 領域を確保 被参照列のみから成る レコードを、結果 バッファに書き出す 比較的複雑な処理は、常に32スレッドを飽和させるように設計変更！ GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 37 2022
- 38. PostgreSQL Backend リソース管理の改善 CUDA Contextの生成ごとに消費されるワーキングメモリの節約 従来のアーキテクチャ 新しいアーキテクチャ GPU PostgreSQL Backend CUDA Context PG-Strom PostgreSQL Backend CUDA Context PG-Strom PostgreSQL Backend CUDA Context PG-Strom Postmaster Process working memory working memory working memory fork(2) GPU PG-Strom PostgreSQL Backend Background Worker CUDA Context GPU Service (multi- threads) Postmaster Process working memory fork(2) PG-Strom Local connection to GPU Service ? コード品質やでバック手法に対する知見が十分で なかった時期、デバッグを容易にするメリット。 ? メモリコピーのコストをやや過大に見積もり。 ? CUDA Context初期化時間、およびワーキング メモリ（数百MB～1GB）の節約。 ? CUDA Contextスイッチの削減とGPU使用率改善 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 38 2022
- 39. DPUへの対応（1/2） GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 39 PCI-Eバス SSD?GPU データ転送量：大 データ転送量：小 GPU?CPU SQLを 実行 Smart-SSD データ転送量：小 Smart-SSD ? CPU PCI-Eバス NAND Flash （記憶素子） DPU GPU データ転送量：大 NAND Flash ? DPU NVME-SSD Smart-SSDの内部 現行技術：GPU-Direct SQL 新技術：Smart-SSD / Smart-NIC 版 PG-Strom Smart-NIC Smart-NIC ? CPU DPU 高速N/Wポート RDMA対応 100Gb/200Gb N/W NVME/GPUの能力をフルに 引き出したとしても、ここ がボトルネックになってし まう。 2023
- 40. DPUへの対応（2/2）～ 直感的なアーキテクチャの理解 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 40 ? 現在入手可能で最も強力なプロセッサで ある GPU を使用し、全力でNVME-SSDから データを流し込んで処理する方式。 ? GPUの計算能力に利点はあるが、PCI-E 4.0 では20.0GB/s程度、PCI-E 5.0でも40.0GB/s 程度で律速してしまい、それ以上データ を投入できなくなる。 （GPUが遊んでしまう問題） ? 今後、2023年以降に Smart-NIC/-SSD製品の 市場投入が本格的に進む。 ? GPUやCPUのようにパワフルではないが、 DPUはデータに近いところでSQLワーク ロードを処理できるため、転送すべき データ量自体を減らす事ができる。 ? 低消費電力で、サーバあたりの搭載数を 増やす事ができる。 GPU-Direct SQL （動力集中方式） Smart-SSD / Smart-NIC （動力分散方式） 2023
- 41. PG-Strom 10年の歩みと、その次の未来を振り返る。 ? はじまりは『あ、面白そう』から。 ? 最適な設計は、その年代に利用可能なテクノロジに左右される。 ? 2014年に『デバッグ難しい』と投げ出したアーキテクチャも、 2022年にはソフトウェアスタックが安定し、再びメリットが勝ることに。 ? 2016年にPascal世代で memory overcommit が使えるようになった事で、 Maxwell以前に悩んでいたメモリ管理から解放される事となった。 ? PG-Stromの方向性を決定づけた GPU-Direct SQL 機構 ? GPU-DBとしては珍しい「I/Oワークロード」に注力するという方向性 ? PCI-E 4.0世代で 20GB/s、PCI-E 5.0世代では 40GB/s のデータ処理能力を ? 2021年からはNVIDIAもGPUDirect Storageという形で公式サポート ? より“データに近い場所”を追求～Smart-NIC/-SSD対応 ? GPUほど強力ではないが、省電力かつ搭載台数を増やしやすい ? 2023年以降、各社からリリースされる製品への対応を準備中。 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 41
- 42. オモシロ技术を、カタチにする。