GPUDirect SQL on NFS-over-RDMAを試す - KaiGaiの俺メモ
タイトルでほぼほぼ出オチですが、先日、NVIDIAからCUDA Toolkit 11.4と共にリリースされた新機能GPUDirect Storage 1.0のドキュメントを読んでいると、面白い記述を見つけた。 曰く、MOFEDドライバ5.3以降と、Mellanox Connect-X4/5の組み合わせで、NFS-over-RDMAとGPUDirect Storageを組み合わせ、リモートのNFS区画からローカルのGPUへと直接のデータ転送を行う事ができるようになる、と。 14.10. NFS Support with GPUDirect Storage This section provides information about NFS support with GDS. 14.10.2. Install GPUDirect Storage Support for the NFS Cli
秒速で10億レコードを処理する話 - KaiGaiの俺メモ
これまでのPG-Stromの性能測定といえば、自社保有機材の関係もあり、基本的には1Uラックサーバに1CPU、1GPU、3～4台のNVME-SSDを載せた構成のハードウェアが中心だった。*1 ただソフトウェア的にはマルチGPUやNVME-SSDのストライピングに対応しており、能力的にどこまで伸ばせるのかというのは気になるところである。 そこで、方々に手を尽くして、次のようなベンチマーク環境を整備してみた。 （機材をお貸し頂いたパートナー様には感謝感激雨あられである） 4UサーバのSYS-4029GP-TRTというモデルは、GPUをたくさん乗っけるためにPCIeスイッチを用いてPCIeスロットを分岐している。ちょうど、PCIeスイッチ1個あたり2個のPCIe x16スロットが用意されており、同じPCIeスイッチ配下のデバイス同士であれば、完全にCPUをバイパスしてPeer-to-Peerのデ
PostgreSQL v11新機能先取り：Hash-PartitioningとParallel-Append - KaiGaiの俺メモ
今回のエントリーは PostgreSQL Advent Calendar 2017 - Qiita に参加しています。 PG-Stromの視点からも、PostgreSQL v11には首を長くして待っていた機能が2つ入っている。 その１：Hash-Partitioning github.com その２：Parallel-Append github.com Hash-Partitioningというのは、PostgreSQL v10で追加されたテーブルパーティショニング機能の拡張で、日付時刻などの幅（Range）でパーティション化を行うのではなく、レコードの値をハッシュ関数に通して得られた値を元に、振り分ける先の子テーブルを選択して書き込みを行うというもの。 特徴としては、データの母集団が特異なものでない限り*1、各子テーブルへの書込みは均等に平準化されることになる。これは後で説明する通り、子テ
gstore_fdw: GPUメモリをSQLで読み書き、そして…。 - KaiGaiの俺メモ
昨年、PGconf.ASIAで発表したPL/CUDAによる創薬ワークロードの高速化実験のテーマであるが、 kaigai.hatenablog.com 実測したベンチマークを見ると、奇妙な傾向が見てとれる。 このワークロードにおける計算量は「Qの行数×Dの行数」であるので、Dの行数が同じ1000万行であるならば、Qの行数が1000のケース（22.6s）に比べ、Qの行数が10のケース（13.4s）の実行時間はもっと顕著に短時間でなければならない。 計算量が1/100なのに、実行時間は半分弱にしかなっていない。 実はこれは、化合物同志の類似度を計算するための時間だけでなく、PL/CUDA関数に与える引数をセットアップするための時間に12秒程度を要しており、アムダールの法則を引用するまでもなく、類似度の計算を高速化するだけでは処理速度はこれ以上伸びないのである。 PL/CUDA関数の引数として行列
NECを退職し、新会社を立ち上げました。 - KaiGaiの俺メモ
ご報告が遅れましたが、6月30日付で新卒の2003年から14年あまり勤務したNECを退職しました。 また、本日、東京法務局品川出張所においてヘテロDB株式会社の登記申請を行い、また、併せて新会社のチーフアーキテクト兼代表取締役社長に就任しました。 今後は、前職では実現できなかった、GPUやSSDなどヘテロジニアスな計算機資源を活用する事で、高性能、低価格、使いやすさを両立するデータベース製品の事業化を目指していく事になります。 どうぞよろしくお願いいたします。 web: http://heterodb.com/ 弊社が入居する西大井創業支援センター（品川区） 10年以上も勤務した会社を辞めてスタートアップを立ち上げるというのは、おそらく人生の中でも上位に食い込むビッグイベントの一つだと思うので、今の決意や創業に至る一連の流れについて記録を残しておこうと思います。 （書き下してみたら意外と長
進捗）SSD-to-GPU ダイレクトSQL実行機能 - KaiGaiの俺メモ
ここ暫くブログでまとめていなかった、SSD-to-GPUダイレクトSQL実行機能の進捗について。 この機能をかいつまんで言うと、NVMe-SSDに格納されているPostgreSQLのデータブロックをGPU RAMに直接転送し、そこでSQLのWHERE句/JOIN/GROUP BYを実行することで見かけ上のI/O量を削減するという代物である。 NVIDIAのTesla/Quadro GPUが対応するGPUDirect RDMA機能を使い、SSD<=>GPU間のデータ転送を仲介するLinux kernel moduleを使えば、CPU/RAMにデータをロードする前にGPU上での処理を行うことができる。 しばらく前からScan系の処理には対応していたが、JOIN/GROUP BYへの対応を加え、さらにPostgreSQL v9.6のCPU並列にも追従したということで、簡単なベンチマークなら取れる
AWSのP2.*インスタンスで PG-Strom を試す - KaiGaiの俺メモ
従前、AWSの提供するGPUインスタンス g2.* に搭載されているGPUはGRID K520というちょっと古いモデルで、PG-Stromは非対応だった。 理由は、一年ほど前にComputing Capability 3.5以降で対応のDynamic Parallelism機能を使うように全面的に作り直したからで、詳細は以下のエントリを参照。 kaigai.hatenablog.com その後、昨年の10月にAWSは新世代*1のGPUインスタンスを新たにリリースした。 japan.zdnet.com これでPG-Stromの動作要件を満たすようになった上に、特にメモリ搭載量で相応の強化が行われたため、例えばPGconf.ASIAで発表を行った創薬領域の類似度サーチのような、I/Oが支配的でないようなワークロードであれば相応の効果が見込める、ハズである。 発表から少し間が空いてしまったが、p
TOASTメカニズム - KaiGaiの俺メモ
PostgreSQLで可変長データ型を扱う時、内部的にはTOASTと呼ばれる機構を利用して、別の隠しテーブルに可変長のデータを格納するようになっている。この時、可変長のデータは適正な長さに分割されて格納されるので、タプル一個あたりのデータ長がブロックサイズを超える事はない。 この辺の処理を見てみたので、後々のためのメモ。本当は LargeObject の格納に使ったり、巨大な Bytea データの一部分を取り出すような関数を実装するために使えないかと思ってみたり。 TOASTテーブルの構造 テーブルを定義すると、こっそりとそのテーブル専用のTOASTテーブルというものが作成される。SQL的に記述すると以下のような構造を持っており、利用者は直接アクセスできない。 CREATE TABLE pg_toast_<relid> ( chunk_id oid, chunk_seq int4, chu
PostgreSQLのデータ構造はなぜ並列プロセッサ向きではないか。 - KaiGaiの俺メモ
今年もPostgreSQL Advent Calendar 2015に参加しています。 前からちょくちょく『PG-StromってXeon Phiだとどーなんですか？』的な質問を受ける事があんですが、データ構造から見て難しいので『勘弁！』という理由を紹介してみたいと思います。 PostgreSQLのレコードは、内部的には HeapTupleHeader 構造体を先頭とする可変長データとして表現されています。 struct HeapTupleHeaderData { union { HeapTupleFields t_heap; /* MVCC関連情報 */ DatumTupleFields t_datum; /* xmin, xmaxとか... */ } t_choice; /* current TID of this or newer tuple */ ItemPointerData t_
AWSでPG-Strom - KaiGaiの俺メモ
PG-Stromを動かそうという時に、GPU自体は安価で手に入れやすい部品なのだけども、普段使いのLinuxサーバにそうそう都合よくGPUが挿さっている人はマジョリティではないかもしれない。 という事で、簡単にPG-Stromをお試しするために、AWSでのAMIイメージを作ってみました。 AMI-Idは ami-51231b50 で、GPUインスタンス（g2.x2large）を使えば簡単にトライアルできます。 以下に手順をご紹介しますが、デプロイ完了まで10分以下。こりゃ便利だわ・・・。 ① Launch Instance を選択する ② キーワード「strom」で検索するか、上記のami-51231b50でAMIイメージを検索する。 AMIイメージはちょくちょく更新されるので、キーワード検索を使った方が間違いがないかも。 ③ 続いてインスタンスタイプを選択。もちろんGPUインスタンス（g
さらばドイツ - KaiGaiの俺メモ
2011年2月にドイツへ赴任し、以降2年10ヵ月間、SAP社とのアライアンス業務に携わっていたわけですが、11月末で任地での業務を終了し日本へと戻る事になりました。 振り返れば、初めてフランクフルトの空港に到着した後、一歩外へ出たら氷点下の世界（注：ドイツの2月です）で『こりゃトンデモない場所に来たもんだ』と思ったものですが、まぁ、住めば都で何とかなるもんですな。 オフィスはドイツ南西のWalldorf市（SAP本社がある）。住むには少し規模が小さな街なので、隣のHeidelberg市の旧市街のマンションを借り、1月遅れで嫁さんも日本からやってきました。 お仕事的には、2011年前後というのはちょうどSAP社がSUSE LinuxベースのインメモリDB製品 "SAP HANA" をぶち上げ始めた頃で、主に技術面でSAPやSUSEとの折衝や、HANA認定取得の実作業というのが駐在中のメインの
しゅとろ〜む、しゅとろ〜む - KaiGaiの俺メモ
昨年、オタワでTim Child氏の発表を聞いて以来、実装できないものかと思って暖めていたアイデアがある。GPUの処理能力を使って、PostgreSQLの検索処理を高速化できないか？というものである。 特に複雑な計算を含むクエリの場合、Index-Scanに落ちないで、全件スキャンが走ることが往々にしてあるが、こういったケースで有効に作用するのではなかろうか？という着想である。 クリスマス休暇の間、割とまとまった開発時間を取る事ができたので、PostgreSQLのFDW(Foreign Data Wrapper)として動作するモジュールを作成してみた。 モジュールの名前は PG-Strom で、ドイツ風に『しゅとろ〜む』と発音する。 これは GPU の処理単位である Streaming Multiprocessor に由来する。 もちろん、現状のFDWのI/F前提なので、更新は不可能でソー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
