pgbenchのスレッドとクライアント (第51回 PostgreSQLアンカンファレンス@オンライン 発表資料)
- 1. © 2025 NTT DATA Group Corporation © 2025 NTT DATA Group Corporation 1 第51回 PostgreSQLアンカンファレンス pgbenchのスレッドとクライアント 2025年1月31日 NTTデータグループ 技術革新統括本部 笠原辰仁
- 2. © 2025 NTT DATA Group Corporation 2 自己紹介 笠原辰仁 NTTデータグループ所属 長年PostgreSQLのサポート、技術支援、性能検証や周辺ツールの開発などをしてきました。 最近はYugabyteDBなどの分散SQLデータベースなども取り扱っています。
- 3. © 2025 NTT DATA Group Corporation 3 はじめに PostgreSQLに付随するpgbenchを使ったことがある人も多いと思います。 本日はこのpgbenchがどのようにして大量のクライアント(コネクション)を生成し、PostgreSQLに 対して並列で負荷をかけているのか？を解説します。 特に-jオプション(スレッド数)と-cオプション(クライアント数)の関係性について悩まれる方も多いと 思うので、そこにスコープをあてた内容にしています。 資料は後日に https://www.slideshare.net/nttdata-tech で公開します。
- 4. © 2025 NTT DATA Group Corporation 4 pgbenchとは もともとはPostgreSQLのcontribにあったベンチマークツールで、PostgreSQL9.5(2016年リリース)から はPostgreSQL本体に取り込まれています。 TPC-Bのワークロードをデフォルトで実施するほか、ユーザ定義のカスタムスクリプトによる柔軟なワークロー ドをシミュレート可能です。同実行数、試験時間、実行トランザクション総数、スロットル調整(スループット の指定)などベンチマークツールに必要とされる機能は一通り持っています。 その他、変数の設定/生成(ランダム値、ハッシュ値など)/演算などを行うpgbench組み込みの関数や演 算子、メタコマンドが揃っており高度なシナリオを実施することができます。ベンチマーク結果の詳細なログや サマリレポート機能なども備えているため使い勝手はとても良いです。 注意点としてはDBに対するSELECT結果などを利用することができない、などです。 (参考：pgbenchのマニュアル) https://www.postgresql.jp/document/16/html/pgbench.html
- 5. © 2025 NTT DATA Group Corporation 5 【参考】 pgbenchの実行例 $ pgbench -c 10 -T 10 -r pgbench (17.2) starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 1 query mode: simple number of clients: 10 number of threads: 1 maximum number of tries: 1 duration: 10 s number of transactions actually processed: 1823 number of failed transactions: 0 (0.000%) latency average = 55.008 ms initial connection time = 17.557 ms tps = 181.791874 (without initial connection time) statement latencies in milliseconds and failures: 0.004 0 ¥set aid random(1, 100000 * :scale) 0.001 0 ¥set bid random(1, 1 * :scale) 0.001 0 ¥set tid random(1, 10 * :scale) 0.001 0 ¥set delta random(-5000, 5000) 0.284 0 BEGIN; 0.440 0 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid; 0.279 0 SELECT abalance FROM pgbench_accounts WHERE aid = :aid; 21.981 0 UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid; 26.402 0 UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid; 0.333 0 INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); 5.128 0 END;
- 6. © 2025 NTT DATA Group Corporation 6 pgbenchのスレッド数とクライアント数のオプション pgbenchにはスレッド数とクライアント数を指定するオプションがあります。以下はマニュアルの記載 をそのまま持ってきたものです。 -c/--client 模擬するクライアント数、つまり、同時に実行されるデータベースセッション数です。 デフォルトは 1です。 -j/--jobs pgbench内のワーカースレッド数です。 複数のスレッドを使用することはマルチCPUマシンで 有用になります。 クライアントは利用可能なスレッドの間でできる限り均等に分散されます。 デ フォルトは1です。 (補足：ちなみにクライアント数より大きい数値をスレッド数に指定するとスレッド数はクライアント 数と同じとなります。)
- 7. © 2025 NTT DATA Group Corporation 7 pgbenchのスレッドとクライアント ワーカースレッドは指定したクライアント数を均等に分担します。 Thread Conn Conn Conn Conn Conn Conn Thread Conn Conn Conn Conn Conn Conn Thread Conn Conn Conn Conn Conn Conn Thread Thread Thread -j 1 –c 6の場合 -j 2 –c 6の場合 -j 3 –c 6の場合
- 8. © 2025 NTT DATA Group Corporation 8 pgbenchはどのようにして多数のクライアントを制御しているか？ pgbenchのワーカースレッドがクライアントを制御していますが、以下にして数百ものクライアントを さばいているのか？ポイントはlibpqの非同期コマンドの利用です。 pgbenchはC言語で書かれており、PostgreSQLへの接続やクエリの実施にPostgreSQLのC クライアントライブラリであるlibpqを使っています。libpqにはPostgreSQLへクエリを発行した際、 その結果を待たない(発行の成功可否だけ確認する)非同期処理用のAPIがあります。 この処理を使って高速に多数の接続の処理をさばいています。 非同期処理のAPI例 int PQsendQuery(Conn1 *conn, const char *command); 結果を待つことなく、サーバにコマンドを発行します。 コマンドの登録に成功した場合1が、失敗した場合0が返されま す。 (後者の場合、PQerrorMessageを使用して失敗についてのより多くの情報を取り出してください。) 参考：非同期コマンドの処理 https://www.postgresql.jp/document/16/html/libpq-async.html
- 9. © 2025 NTT DATA Group Corporation 9 pgbenchによる内部処理の概要 pgbenchのスレッドにおける処理概要は以下の通りです。 • 事前処理 • これはスクリプト内のコマンドのパースや事前のVACUUMなど • スレッド生成 • 規定数の接続生成 • 処理実施 (以下の処理高速に繰り返す) • 各接続ごとに: 非同期クエリの実施 or (未完了)クエリ完了の待機 or (完了後)次のクエリ準備 • クエリやトランザクション単位レスポンスを計算しログに書いたりスレッド単位の性能情報を記録 • メインスレッドは他スレッドの性能情報を集約し、定期レポートを表示 • 規定の時間/Tx数に達したら完了 • メインスレッドは各スレッドの性能情報を集計しレポート 基本的にこの流れとなります。スレッドでは各接続ごとに状態をステートマシンとして管理しており、ステートを どんどん遷移させています。
- 10. © 2025 NTT DATA Group Corporation 10 pgbenchによる内部処理の概要 pgbenchのスレッドにおける処理概要を簡単に図示すると以下の通りです。 Thread Conn1 Conn2 Conn3 Thread Conn1 Conn2 Conn3 Thread Conn1 Conn2 Conn3 ①Conn1へ非同期でクエリ実施。 結果を待たず次の接続へ。 Thread Conn1 Conn2 Conn3 Thread Conn1 Conn2 Conn3 Thread Conn1 Conn2 Conn3 ②Conn2へ非同期でクエリ実施。 結果を待たず次の接続へ。 Send Send Send ③Conn3へ非同期でクエリ実施。 結果を待たず次の接続へ。 この間にConn1の結果受領完了。 Result ④Conn1のクエリ完了を確認し次のクエリを実施。 結果を待たず次の接続へ。 Send ⑤Conn2のクエリの未完了を 確認し次の接続へ。 この間にConn3の結果受領 Result Send ⑥ Conn3のクエリ完了を確認し次のクエリを実施。 結果を待たず次の接続へ。
- 11. © 2025 NTT DATA Group Corporation 11 【参考】 pgbenchの各接続のステート 正常系の代表的なステート遷移。(異常系やスロットルの処理などは除いて抜粋しています) 前述の処理はかなり簡素化して表現しており、実際には多様なステートを持っています。接続毎にステート をひとつずつ進めながら(遷移させながら)処理を行っています。 CSTATE_CHOOSE_SCRIPT CSTATE_START_TX CSTATE_FINISHED CSTATE_START_COMMAND CSTATE_WAIT_RESULT CSTATE_END_COMMAND CSTATE_END_TX 実行するスクリプト選択からスタート トランザクション開始 次のコマンドがない コマンド送付成功 (非同期処理) コマンド結果全受領 (非同期処理) 次のコマンドの実施へ 実施時間/Txが規定に達した トランザクション完了 次のスクリプトへ FINISHEDで完了 スクリプトを選択
- 12. © 2025 NTT DATA Group Corporation 12 スレッド数の指定方針 1スレッドで多数の接続を受け持つ場合、暇になるクライアントが増える可能性がある。特にDBサーバが高 スペックな場合にはその傾向が出やすい。 つまりPostgreSQLに十分に負荷をかけきれずpgbenchネックになる可能性がある。厄介なことにマルチコ ア環境だと見た目でpgbenchネックかどうか分かりにくい・・ そのため、スレッド数を調整するのがおススメ・・だが、スレッド数はどれくらいにしておくのが良いのか？ • 軽量なクエリかつ接続数が多い場合はスレッド数を増やすことを検討 • pgbenchを動かす負荷クライアントマシンのコア数が目安 • スレッド数が多すぎるとコアの競合が顕在化したり、ログが増えて集計が面倒なので注意 ちなみにpgbenchのマルチスレッドはPostgreSQL9.0でサポートされました。 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=3da0dfb4b1460c3701abc 8ed5f516d138dc4654c 2009年の当時では8core(物理4core HT on)でスレッド数8にすると最も良いスループットを叩き出せ たようです。おそらく現在でも同様の傾向ではないかと思います。
- 13. © 2025 NTT DATA Group Corporation 13 おわりに pgbenchのスレッドとクライアントについて解説している資料があまり見当たらなかったため、本日 紹介してみました。 ベンチマークは諸条件を適切に理解し設定しないと、正しく性能を測ることができません。 スレッド数指定以外にも、十分な時間を測定できているか？(チェックポイントやauto vacuumの 発生を意識しているか)、スケールファクタは適切か？(小さすぎるとロック待ち、大きすぎるとIOネッ ク)などなど、注意することが多いです。 オプションの意味や作用を意識して適切な測定を心掛けましょう。