An Intelligent Storage?

An Intelligent Storage?
The PG-Strom Project
KaiGai Kohei (tw: @kkaigai)

自己紹介
Database Lounge Tokyo #2 - An Intelligent Storage?2
▌海外浩平（tw: @kkaigai）
▌PostgreSQL開発者（約10年くらい）
▌元々は Linux kernel 開発者でも。
▌PG-Stromの開発をやっています。
 GPU使ってPostgreSQLを早くする拡張モジュール
 最近、SSDにも手を出し始める (NEW!!)
最近の興味

PG-Strom “v2.0” 新機能 – SSD-to-GPU Direct SQL
Database Lounge Tokyo #2 - An Intelligent Storage?
▌Challenges
 PostgreSQLのストレージ層に対する完全な透過性
 shared_buffer、filesystem、page cacheとのconsistencyが必要
▌PG-Strom v2.0に向けて
 NVMe-SSDGPU Direct DMAに対応したLinux kernelドライバ
 当該機能のPG-Strom側での対応（GpuScan、GpuJoin、GpuPreAggが対象）
 I/Oが完了したら、既にSelection、Projection、Join、Aggregation処理が済んでいる
GPU SSD
CPU + RAM
PCI-E
Table
Innertables
ofJOIN
+
③ Make result
set on GPU
① SSDGPU
direct DMA
② Execution of SQL on GPU
(Select, Projection, Join)
④ GPURAM
Data Transfer
New
Data flow
v2.0
traditional
data flow
3

NVIDIA GPU RDMA Direct機構 (1/2)
プロセス
仮想アドレス空間
物理アドレス空間
GPUデバイス
アドレス空間
256MB
PCI BAR1
領域
RAM領域
PCI-Eデバイス
アドレス空間
cuMemAlloc()...GPUデバイスメモリを割り当て
nvidia_p2p_get_pages()
GPUデバイスメモリを、ホスト側
物理アドレス空間にマッピング
DMA転送
4

NVIDIA GPU RDMA Direct機構 (2/2)
$ lspci –v
:
04:00.0 3D controller: NVIDIA Corporation GK110GL [Tesla K20c] (rev a1)
Subsystem: NVIDIA Corporation Device 0982
Flags: bus master, fast devsel, latency 0, IRQ 100
Memory at 93000000 (32-bit, non-prefetchable) [size=16M]
Memory at 33fc0000000 (64-bit, prefetchable) [size=256M] <-- ココ(!)
Memory at 33fd0000000 (64-bit, prefetchable) [size=32M]
Capabilities: <access denied>
Kernel driver in use: nvidia
:
$ nvidia-smi -q
:
FB Memory Usage
Total : 4095 MiB
Used : 15 MiB
Free : 4080 MiB
BAR1 Memory Usage
Total : 256 MiB
Used : 2 MiB
Free : 254 MiB
Compute Mode : Default
:
5
Tesla K40/K80やM40など
ハイエンド製品は、
16GB~32GB分の設定
 搭載物理メモリの全部を
一度にマップする事も可能

nvme_stromドライバ
(made by KaiGai)
Application
NVMe-Stromドライバ (1/3) – 概要
/opt/nvme/*
Filesystem
/dev/nvidia
nvidiaドライバ
RDMA
Direct
サポート
Tesla or
Quadro GPU
NVMe-SSD
open(2)DMA
要求
GPU
メモリ
cuMemAlloc()
mapping
要求
mapped
GPU
memory
devptr fdesc
/dev/nvme0n1p1
nvmeドライバ
DMA
キュー
/proc/nvme-strom
6

NVMe-Stromドライバ (2/3) – ioctl(2)コマンドの一覧
▌STROM_IOCTL__CHECK_FILE
 ターゲットファイルが SSD-to-GPU Direct DMA に対応しているかどうかを調べる。
▌STROM_IOCTL__MAP_GPU_MEMORY
 GPUメモリをホスト側物理アドレス空間にマップする。
▌STROM_IOCTL__UNMAP_GPU_MEMORY
 ホスト側物理アドレス空間からGPUメモリをアンマップする。
 なお、cuMemFree()すると勝手にアンマップされる。
▌STROM_IOCTL__LIST_GPU_MEMORY
▌STROM_IOCTL__INFO_GPU_MEMORY
 ホスト側物理アドレスにマップしたGPUメモリの情報を取得する。
▌STROM_IOCTL__MEMCPY_SSD2GPU
 SSD-to-GPU Direct DMAを使って、指定したファイルの特定領域をGPUメモリへ転送。
 同期転送モード。転送の完了までは呼び出し元には戻らない。
▌STROM_IOCTL__MEMCPY_SSD2GPU_ASYNC
 SSD-to-GPU Direct DMAを使って、指定したファイルの特定領域をGPUメモリへ転送。
 非同期転送モード。DMA要求をキューイングすると即座に復帰する。
▌STROM_IOCTL__MEMCPY_SSD2GPU_WAIT
 非同期SSD-to-GPU Direct DMAの完了を待機する。
7

NVMe-Stromドライバ (3/3) – 制限事項
▌対応環境
 ファイルシステム ... Ext4, XFS
 NVMe-SSD ... Inbox ドライバで動作する NVMe-SSD
 独自ドライバを使用する ioDrive や FlashMax はアウト。
 海外は Intel SSD 750 (400GB) にて動作確認。
 Soft-RAID ... 非対応
 現状、生デバイスの上に構築したExt4, XFSのみ。
 RAID-0やRAID-1であれば可能性あり。
▌制限事項
 転送元ファイルがOSのページキャッシュに乗っており、かつ、当該ページが
先行するI/Oによって dirty 状態である時、転送性能が極めて低下
（20~30MB/s程度; AVXレジスタ使用時でも500MB/s程度）
根本解決は、nvidiaドライバがin-kernel DMAのためのI/Fを公開する事
Dirty-Pageは仕方ないのでmemcpy()で処理するしかない。
それ以外はSSD上のデータと同一なので、OSのページキャッシュに載ってい
ても SSD-to-GPU DMA を使う事である程度回避。
8

ページキャッシュの取り扱いに関する課題
 ファイルがOSにキャッシュされている場合は RAM-to-GPU DMAが最適手段。
 kernel空間からRAM-to-GPU DMAをキックするAPIが提供されていない。
 代替手段： ioremap() + memcpy_toio() .... しかし非常に低速
 現在、NVIDIA社に問題をエスカレーション中。
PostgreSQL
shared buffer
Linux
page cache
Blocks on
NVMe SSD
block-i0 block-i1 block-i2 block-i3
GPU
device RAM
cuMemcpyHtoDAsync() SSD-to-GPU Direct DMA
ioremap() +
memcpy_toio()
9
10GB/s
2GB/s
500MB/s

単純I/Oにおけるパフォーマンス
 32MB x 6個のバッファを使用。バッファが空くたび次々に非同期DMAをキック。
 NVMe-Stromおよび、I/Oサイズ毎にVFS経由のロード+RAM2GPU DMAを3パターン。
 測定環境
 CPU: Xeon E5-2670 v3, RAM: 64GB
 Intel SSD 750 (400GB; PCI-E版)
 NVIDIA Tesla K20c (2496core; 706MHz, 5GB GDDR5; 208GB/s)
 OS: CentOS 7 (3.10.0-327.18.2.el7.x86_64), Filesystem: Ext4
カタログ
スペック!!
10

測定に使用したNVMe-SSD
容量
順次128KB
読出し
(最大MB/s)
順次128KB
書込み
(最大MB/s)
ランダム4KB
読出し
(最大IOPS)
ランダム4KB
書込み
(最大IOPS)
インターフェース
400GB 2,200 900 430,000 230,000 PCIe 3.0 x4
800GB 2,100 800 420,000 210,000 PCIe 3.0 x4
1.2TB 2,500 1,200 460,000 290,000 PCIe 3.0 x4
出展： Intel社ウェブサイトより
http://www.intel.co.jp/content/www/jp/ja/solid-state-drives/solid-state-drives-750-series.html
11

参考) VFSのパフォーマンス
 ファイルシステムを介してSSD上のブロックをCPU/RAMにロードした時のスループット
 dd if=/opt/nvme/100GB of=/dev/null bs=XXX (iflag=direct)
 I/Oサイズ毎に32MB, 32KB, 8KBの3種類。およびDirect I/Oのケースでトライ
12

PG-Strom環境下におけるパフォーマンス (1/2)
▌測定条件
 NVMe-SSDデバイス上に格納した 64GB / 7億行の単純テーブルに対し、以下の３クエリを実行
 Q1: 比較的単純な条件句を含むスキャンクエリ
 Q2: 比較的複雑な条件句を含むスキャンクエリ
 Q3: 文字列マッチングを含むスキャンクエリ
13

PG-Strom環境下におけるパフォーマンス (2/2)
▌測定結果より読み取れる事
 従来の性能限界 ... 64GB / 140sec = 468MB/s
 Raw-I/Oのスループット (587.37MB/s) に、その他の処理で20%が載った程度？
 NVMe-Strom適用による効果
 Q1の処理スループット 64GB / 43sec = 1524MB/s
 理論帯域2200MB/sなので、CPU+GPUハイブリッド並列の２並列で帯域を使い切れそう。
14
従来の
性能限界

参考）測定に使用したテーブル定義、クエリ
CREATE TABLE t_64g (id int not null,
x float not null,
y float not null,
z float not null,
memo text);
INSERT INTO t_64g (SELECT x, random()*1000, random()*1000,
random()*1000, md5(x::text)
FROM generate_series(1,700000000) x);
postgres=# ¥d+
List of relations
Schema | Name | Type | Owner | Size | Description
--------+------------------+-------+--------+---------+-------------
public | t | table | kaigai | 965 MB |
public | t_64g | table | kaigai | 66 GB |
Query-1) 比較的単純な条件句を含むスキャンクエリ
SELECT * FROM t WHERE x BETWEEN y-2 AND y+2;
Query-2) 比較的複雑な条件句を含むスキャンクエリ
SELECT * FROM t_64g WHERE sqrt((x-200)^2 + (y-300)^2 +
(z-400)^2) < 10;
Query-3) 文字列マッチングを含むスキャンクエリ
SELECT * FROM t WHERE memo LIKE '%abcd%';
15

PCI-E
CPUから見た光景
周辺機器
【周辺機器への要求】
SSDのセクタ番号100~199を
読み出して、その中から、
x LIKE ‘%hoge%’
を満たすレコードだけを返し
てほしい。
オイラはPostgreSQLの
データ形式を解釈して
レコードを評価するよ拙者、セクタ番号
100～199を
読み出すでござる。
b c xa
abchoge
xyhogez
hoge
hogehoge
:
:
:
実行結果
▌SSDとGPUのペアを、PCI-Eバスの先に繋がった一つのストレージシステムと
見なせば、SQL由来のバイナリをGPUで実行、前処理を行う。
 あたかもストレージがSQLを理解して動作するかのように見える。
16
ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!!!

【拡散希望】 – ユーザを探しています。
▌試用ユーザ募集中
 GPUを活用した高速 In-database Analytics/Computing に興味のある方。
 教師なし学習アルゴリズム (非階層/階層型クラスタリング) を実装し、実データによる
評価を行いたい。
 評価環境の提供と、アルゴリズムの実装はPG-Stromプロジェクトで実施。
ワークロードと評価用データをご提供いただける方を探しています。
 評価環境： CPU: E5-2670v3 x2, RAM: 384GB, GPU: Tesla K20 or GTX1080
CREATE FUNCTION kmeans(matrix, int)
RETURNS vector
AS $$
$$ LANGUAGE ‘plcuda’;
User define CUDA logic
(通常のSQL関数として記述可能)
User defined
CUDA code
PG-Strom’s matrix
support routines
GPU Kernel for
SQL function
‘kmeans()’
実行時ビルド
PG-Strom
Input
buffer
Output
buffer
SQL関数実行結果
matrixのロード
ユーザCUDAロジックの定義：

今後の展望
PostgreSQL, being the top runner of heterogeneous era
NVMe-Strom
SSDGPUの
ダイレクトDMA
PG-Strom
SQLワークロードの
“超”並列実行
 WHERE句
 JOIN
 GROUP BY
 PROJECTION
設計・開発中(?)
トランザクション
ログの高速書き出し
PL/CUDA
HPC水準の計算能力による
In-database Analytics
18
チョットオマケ

Block Device Driver
一般的なトランザクションログの書き出し
Storage Controller
DMA Buffer
FilesystemPage Cache
PostgreSQLWAL Buffer
File + offset, length  Get Block Numbers
write(2)
Submit DMA Requests
Transaction Logs
fsync(2)

Block Device
Driver
アイデア： Zero-copy WAL write with NVMe-SSD
Storage Controller
Filesystem
PostgreSQLWAL Buffer
Get Block Numbers
Submit DMA Requests
Transaction Logs
Enqueue DMA Requests
ioctl(2)
DMA Buffer
KaiGai’s
Kernel
Module
ioctl
handler
WRITE & FLUSH
commands
make it persistent

NVMe-SSDはいいぞ。
 pgbench使用。スケールファクタ=1024、クライアント数を1～1000まで増加。３回の中央値。
 CPU: E5-2670v3 (22C, 2.3GHz)、RAM: 384GB
 SSD: Intel SSD 750 (400GB)
 HDD: SAS 300GB (10krpm; RAID5 x8)

更なる性能向上はあり得るか？
 トランザクションログ書き出しの有無で 50% の性能差
 では、もしトランザクションログ書き出しの性能（レイテンシ）を限りなく０に近付ける
事ができたら？
 何か面白そうな事ができそうな気がします。:-)

An Intelligent Storage?

More Related Content

What's hot (20)

Similar to An Intelligent Storage? (20)

More from Kohei KaiGai (20)

An Intelligent Storage?