Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Kohei KaiGai, profile picture
Uploaded byKohei KaiGai
PDF, PPTX2,517 views

An Intelligent Storage?

SSD-to-GPU Direct DMAを用いて、（見かけ上、）GPUがI/Oを高速化するというお話です。 オマケで、NVMe-SSDを最大限活用してWAL書き込みを高速化する話も。

Technology◦
An Intelligent Storage? The PG-Strom Project KaiGai Kohei (tw: @kkaigai)
The PG-Strom Project 自己紹介 Database Lounge Tokyo #2 - An Intelligent Storage?2 ▌海外 浩平 （tw: @kkaigai） ▌PostgreSQL開発者 （約10年くらい） ▌元々は Linux kernel 開発者でも。 ▌PG-Stromの開発をやっています。  GPU使ってPostgreSQLを早くする拡張モジュール  最近、SSDにも手を出し始める (NEW!!) 最近の興味
The PG-Strom Project 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
The PG-Strom Project NVIDIA GPU RDMA Direct機構 (1/2) Database Lounge Tokyo #2 - An Intelligent Storage? プロセス 仮想アドレス空間 物理アドレス空間 GPUデバイス アドレス空間 256MB PCI BAR1 領域 RAM領域 PCI-Eデバイス アドレス空間 cuMemAlloc()...GPUデバイスメモリを割り当て nvidia_p2p_get_pages() GPUデバイスメモリを、ホスト側 物理アドレス空間にマッピング DMA転送 4
The PG-Strom Project NVIDIA GPU RDMA Direct機構 (2/2) Database Lounge Tokyo #2 - An Intelligent Storage? $ 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分の設定  搭載物理メモリの全部を 一度にマップする事も可能
The PG-Strom Project nvme_stromドライバ (made by KaiGai) Application NVMe-Stromドライバ (1/3) – 概要 Database Lounge Tokyo #2 - An Intelligent Storage? /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
The PG-Strom Project NVMe-Stromドライバ (2/3) – ioctl(2)コマンドの一覧 Database Lounge Tokyo #2 - An Intelligent Storage? ▌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
The PG-Strom Project NVMe-Stromドライバ (3/3) – 制限事項 Database Lounge Tokyo #2 - An Intelligent Storage? ▌対応環境  ファイルシステム ... 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
The PG-Strom Project ページキャッシュの取り扱いに関する課題 Database Lounge Tokyo #2 - An Intelligent Storage?  ファイルが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
The PG-Strom Project 単純I/Oにおけるパフォーマンス Database Lounge Tokyo #2 - An Intelligent Storage?  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
The PG-Strom Project 測定に使用したNVMe-SSD Database Lounge Tokyo #2 - An Intelligent Storage? 容量 順次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
The PG-Strom Project 参考) VFSのパフォーマンス Database Lounge Tokyo #2 - An Intelligent Storage?  ファイルシステムを介して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
The PG-Strom Project PG-Strom環境下におけるパフォーマンス (1/2) Database Lounge Tokyo #2 - An Intelligent Storage? ▌測定条件  NVMe-SSDデバイス上に格納した 64GB / 7億行の単純テーブルに対し、以下の３クエリを実行  Q1: 比較的単純な条件句を含むスキャンクエリ  Q2: 比較的複雑な条件句を含むスキャンクエリ  Q3: 文字列マッチングを含むスキャンクエリ 13
The PG-Strom Project PG-Strom環境下におけるパフォーマンス (2/2) Database Lounge Tokyo #2 - An Intelligent Storage? ▌測定結果より読み取れる事  従来の性能限界 ... 64GB / 140sec = 468MB/s  Raw-I/Oのスループット (587.37MB/s) に、その他の処理で20%が載った程度？  NVMe-Strom適用による効果  Q1の処理スループット 64GB / 43sec = 1524MB/s  理論帯域2200MB/sなので、CPU+GPUハイブリッド並列の２並列で帯域を使い切れそう。 14 従来の 性能限界
The PG-Strom Project 参考） 測定に使用したテーブル定義、クエリ Database Lounge Tokyo #2 - An Intelligent Storage? 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
The PG-Strom Project PCI-E CPUから見た光景 Database Lounge Tokyo #2 - An Intelligent Storage? 周辺機器 【周辺機器への要求】 SSDのセクタ番号100~199を 読み出して、その中から、 x LIKE ‘%hoge%’ を満たすレコードだけを返し てほしい。 オイラはPostgreSQLの データ形式を解釈して レコードを評価するよ 拙者、セクタ番号 100～199を 読み出すでござる。 b c xa abchoge xyhogez hoge hogehoge : : : 実行結果 ▌SSDとGPUのペアを、PCI-Eバスの先に繋がった一つのストレージシステムと 見なせば、SQL由来のバイナリをGPUで実行、前処理を行う。  あたかもストレージがSQLを理解して動作するかのように見える。 16 ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!!!
The PG-Strom Project 【拡散希望】 – ユーザを探しています。 Database Lounge Tokyo #2 - An Intelligent Storage?17 ▌試用ユーザ募集中  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ロジックの定義：
The PG-Strom Project 今後の展望 Database Lounge Tokyo #2 - An Intelligent Storage? 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 チョットオマケ
The PG-Strom Project Block Device Driver 一般的なトランザクションログの書き出し Database Lounge Tokyo #2 - An Intelligent Storage?19 Storage Controller DMA Buffer FilesystemPage Cache PostgreSQLWAL Buffer File + offset, length  Get Block Numbers write(2) Submit DMA Requests Transaction Logs fsync(2)
The PG-Strom Project Block Device Driver アイデア： Zero-copy WAL write with NVMe-SSD Database Lounge Tokyo #2 - An Intelligent Storage?20 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
The PG-Strom Project NVMe-SSDはいいぞ。 Database Lounge Tokyo #2 - An Intelligent Storage?21  pgbench使用。スケールファクタ=1024、クライアント数を1～1000まで増加。３回の中央値。  CPU: E5-2670v3 (22C, 2.3GHz)、RAM: 384GB  SSD: Intel SSD 750 (400GB)  HDD: SAS 300GB (10krpm; RAID5 x8)
The PG-Strom Project 更なる性能向上はあり得るか？ Database Lounge Tokyo #2 - An Intelligent Storage?22  トランザクションログ書き出しの有無で 50% の性能差  では、もしトランザクションログ書き出しの性能（レイテンシ）を限りなく ０ に近付ける 事ができたら？  何か面白そうな事ができそうな気がします。:-)
An Intelligent Storage?