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-SSDGPU Direct DMAに対応したLinux kernelドライバ

当該機能のPG-Strom側での対応（GpuScan、GpuJoin、GpuPreAggが対象）

I/Oが完了したら、既にSelection、Projection、Join、Aggregation処理が済んでいる

GPU SSD

CPU + RAM

PCI-E

Table

Inner

table

s of

JOIN

+

③ Make result set on GPU

① SSDGPU direct DMA

② Execution of SQL on GPU (Select, Projection, Join)

④ GPURAM 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

http://www.intel.co.jp/content/www/jp/ja/solid-state-drives/solid-state-drives-750-series.html














参考) 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 x a 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関数実行結果

matr

ixのロード

ユーザCUDAロジックの定義：


今後の展望


PostgreSQL, being the top runner of heterogeneous era

NVMe-Strom

SSDGPUの

ダイレクトDMA

PG-Strom

SQLワークロードの “超”並列実行

WHERE句 JOIN GROUP BY PROJECTION

設計・開発中(?)

トランザクションログの高速書き出し

PL/CUDA

HPC水準の計算能力による In-database Analytics

18

チョットオマケ


Block Device Driver

一般的なトランザクションログの書き出し


Storage Controller

DMA Buffer

Filesystem Page Cache

PostgreSQL WAL 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

PostgreSQL WAL 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?

Technology