スキャン速度10GB/sへの挑戦～その④ 完結編～ - KaiGaiの俺メモ
今回のエントリは、ここ１年ほど取り組んでいた PG-Strom による大量データのスキャン・集計処理性能改善の取り組みが、当面の目標であったシングルノード10GB/sを達成したという完結編です。（長かった） 要素技術：SSD-to-GPUダイレクトSQL 先ず、PG-Stromのストレージ関連機能について軽くおさらい。 RDBMSに限らず一般論として、GPUなど並列プロセッサの処理性能を稼ぐには、プロセッサコアの数や動作クロック以上に、処理すべきデータをできるだけ大量に供給するかという点が重要。 これは、ハードウェアレベルではキャッシュ階層や容量の設計、あるいはメモリデバイスのデータ転送レートという話になり、最近のGPUだとメモリ読出しの帯域は数百GB/sにも達する。もう少し大局的に見ると、これは、ストレージと計算機をどのように接続し、アプリケーションはこれをどのように制御するのかという話
PostgreSQLとcupyを繋ぐ～機械学習基盤としてのPG-Stromその①～ - KaiGaiの俺メモ
世間の機械学習屋さんは、機械学習・統計解析のライブラリにデータを食わせる時に、どうやってデータを入力しているのだろうか？ 話を聞くに、データを一度CSV形式に落とし込んで、それをPythonスクリプトで読み込むというパターンが多いようではある。 ただ、ある程度大量のデータセットをCSVファイルで扱うようになると、いくつか問題点が露わになってくる。 解析すべきデータセットを切り替えるたびに異なるCSVファイルを用意する事になり、ファイルの取り回しが煩雑である。 前処理をかけた後のCSVファイルがまたできてしまい、ファイルの取り回しが更に煩雑になってくる。 最終的にCSVファイルの所在が誰にも分からなくなってしまい、機械学習・統計解析の元になったファイルが散逸してしまう。 そもそも、GB単位のフラットファイルをシェル上でコピーしたり読み込ませたりするのはそれなりに時間を要する処理である。 デー
俺様スキャンの並列実行 - KaiGaiの俺メモ
PostgreSQL v9.6からはパラレルスキャンが導入される事になっている。 この機能をざっくり説明すると 共有メモリ上に『次に読むブロックの番号』という状態を作っておく。 Gatherノードが複数のワーカープロセスを起動する。 各ワーカーで実行されるSeqScanが『次に読むブロックの番号』をアトミックにインクリメントしながらシーケンシャルスキャンを行う。 結果、個々のワーカーは本来読むべきテーブルの内容を一部しか返却しない。しかし、各ワーカーの実行結果を全てマージするとテーブルの内容は全て読み出されている。（しかも並列に） という代物である。 読み出すブロック番号を共有メモリ上の情報から得ている以外は、全てシングルスレッド実行と同じコードを使用しているところがポイントである。 で、これと同じ事をForeignScanやCustomScanを使用して実装したい場合、並列対応版とそうで
オレオレ Demand Paging - KaiGaiの俺メモ
現在の PG-Strom のアーキテクチャは、PostgreSQLの各バックグラウンドプロセスが個別にCUDAコンテキストを作成し、GPUデバイスメモリを作るという構成になっている。 これは、設計の単純化、特にエラーパスのシンプル化により、全体的なソフトウェアの品質が低い時には開発効率の観点からは意味のあるデザインではあるが、一方で、以下のような問題も同時に抱えている。 CUDAコンテキストの初期化には200ms～400ms程度のオーバーヘッドを要するため、数秒で終わる程度のクエリ処理ではこのコストは無視できない。 一方、CUDAコンテキストの初期化・破棄の回数を抑えるために、一度構築したCUDAコンテキストをキャッシュしておくと無駄にGPU RAMを保持し続ける。CUDAコンテキストあたり～90MB程度のGPU RAMを消費する*1ので、同時並行セッション数が増えてくるとワーキングメモリ
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_
GpuNestedLoop - KaiGaiの俺メモ
現時点でPG-Stromが対応しているワークロードは以下の4つ。 全件探索 (GpuScan) 表結合 (GpuHashJoin) 集約演算 (GpuPreAgg) ソート (GpuSort) これに、GPU内の計算処理で使うデータ型や関数が対応しているかどうかで、GPUオフロードできるかどうかが決まる。 だいたいパッと思い付く程度にSQLクエリ処理で重い(CPUバウンドな)ヤツはカバレッジができてきたけれども、一つ大物が残っている。NestedLoop。 どう実装したものかと思っていたが、よいアイデアが浮かんだので備忘録代わりに。 NestedLoopの場合、結合条件が単純な X=Y の形式ではないので、HashJoinやMergeJoinを用いて効率的に処理する事ができない。要はDBの中で総当たりを行う事になるので非常に重い。 今までに実装した上記の4つのロジックでは、PG-Strom
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
