PostgreSQLのパフォーマンスをベンチマークする方法

データベースのベンチマークの目的は、データベースの機能をチェックするだけでなく、アプリケーションに対する特定のデータベースの動作もチェックすることです。ハードウェアが異なれば、設定したベンチマーク計画に基づいて異なる結果が得られます。サーバー（ベンチマークされている実際のサーバー）を、負荷を駆動するサーバーや、パフォーマンスメトリックの収集と保存に使用されるサーバーなどの他の要素から分離することが非常に重要です。ベンチマークの一環として、次のようなアプリケーションの特性を取得する必要があります。a）アプリケーションは読み取りまたは書き込みを多用していますか？またはb）読み取り/書き込み分割とは何ですか（例：80：20）？またはc）データセットの大きさ、実際の本番データベースを表すデータと構造など

PostgreSQLは世界で最も先進的なオープンソースデータベースです。企業のRDBMSのお客様がデータベースをオープンソースに移行したい場合は、PostgreSQLが最初に評価するオプションになります。

この投稿は以下をカバーしています：

PostgreSQLのベンチマーク方法
PostgreSQLの主なパフォーマンス要因は何ですか
パフォーマンスを向上させるために引くことができるレバーは何ですか
避けるべきパフォーマンスの落とし穴は何ですか
人々が犯す一般的な間違いは何ですか？
システムが実行されているかどうかをどのようにして知ることができますか？どのようなツールを使用できますか？

PostgreSQLのベンチマーク方法

PostgreSQLのベンチマークを行うための標準ツールはpgbenchです。デフォルトでは、pgbenchテストはTPC-Bに基づいています。これには、トランザクションごとに5つのSELECT、INSERT、およびUPDATEコマンドが含まれます。ただし、アプリケーションの動作に応じて、独自のスクリプトファイルを作成できます。デフォルトといくつかのスクリプト指向のテスト結果を見てみましょう。これらのテストには最新バージョンのPostgreSQLを使用します。これは執筆時点ではPostgreSQL10です。 ClusterControlを使用するか、https：//www.openscg.com/bigsql/package-manager/の手順を使用してインストールできます。

マシンの仕様

バージョン：RHEL 6-64ビット
メモリ：4GB
プロセッサ：4
ストレージ：50G
PostgreSQLバージョン：10.0
データベースサイズ：15G

pgbenchツールでベンチマークを実行する前に、コマンドの下でベンチマークを初期化する必要があります：

-bash-4.1$ ./pgbench -i -p 5432 -d postgres
NOTICE:  table "pgbench_history" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_branches" does not exist, skipping
creating tables…
100000 of 100000 tuples (100%) done (elapsed 0.18 s, remaining 0.00 s)
Vacuum…
set primary keys…
done.

NOTICEメッセージに示されているように、ベンチマーク用のトランザクションを実行するために、pgbench_history、pgbench_tellers、pgbench_accounts、およびpgbench_branchesテーブルが作成されます。

10人のクライアントを使った簡単なテストは次のとおりです。

-bash-4.1$ ./pgbench -c 10
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 100/100
latency average = 13.516 ms
tps = 739.865020 (including connections establishing)
tps = 760.775629 (excluding connections establishing)

ご覧のとおり、10クライアントとクライアントあたり10トランザクションで実行されました。それはあなたに739トランザクション/秒を与えました。それはあなたに739トランザクション/秒を与えました。特定の時間実行したい場合は、「-T」オプションを使用できます。通常、15分または30分の実行で十分です。

今のところ、pgbenchの実行方法について話しましたが、オプションについては話しませんでした。ベンチマークを開始する前に、次のアプリケーションチームから適切な詳細を入手する必要があります。

どのような種類のワークロードですか？
同時セッションはいくつですか？
クエリの平均結果セットはいくつですか？
予想されるtps（1秒あたりのトランザクション数）はどれくらいですか？

読み取り専用の作業負荷の例を次に示します。「-S」オプションを使用すると、読み取り専用に該当するSELECTのみを使用できます。 -nは、テーブルのバキュームをスキップするためのものであることに注意してください。

-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15741
latency average = 1916.650 ms
tps = 52.174363 (including connections establishing)
tps = 52.174913 (excluding connections establishing)
-bash-4.1$

ここでのレイテンシーは、すべてのクライアントによって実行された各ステートメントの平均経過トランザクション時間です。与えられたハードウェアで52tpsを与えます。このベンチマークは読み取り専用環境用であるため、postgresql.confファイルのshared_buffersパラメーターとeffective_cache_sizeパラメーターを微調整して、tpsカウントを確認してみましょう。上記のテストではデフォルト値になっているので、値を増やして結果を確認してください。

-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15215
latency average = 1984.255 ms
tps = 68.396758 (including connections establishing)
tps = 68.397322 (excluding connections establishing)

パラメータを変更すると、パフォーマンスが30％向上しました。

pgbenchは通常、独自のテーブルでトランザクションを実行します。読み取りが50％、書き込みが50％のワークロード（または60:40環境）がある場合は、一連のステートメントを含むスクリプトファイルを作成して、予想されるワークロードを実現できます。

-bash-4.1$ cat /tmp/bench.sql 
INSERT INTO test_bench VALUES(1,'test');
INSERT INTO test_bench VALUES(1,'test');
SELECT * FROM test_bench WHERE id=1;
SELECT * FROM test_bench WHERE id=2;
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n -f /tmp/bench.sql 
transaction type: multiple scripts
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 25436
latency average = 1183.093 ms
tps = 84.524217 (including connections establishing)
tps = 84.525206 (excluding connections establishing)
SQL script 1: <builtin: select only>
 - weight: 1 (targets 50.0% of total)
 - 12707 transactions (50.0% of total, tps = 42.225555)
 - latency average = 914.240 ms
 - latency stddev = 558.013 ms
SQL script 2: /tmp/bench.sql
 - weight: 1 (targets 50.0% of total)
 - 12729 transactions (50.0% of total, tps = 42.298662)
 - latency average = 1446.721 ms
 - latency stddev = 765.933 ms

今日のホワイトペーパーをダウンロードするClusterControlを使用したPostgreSQLの管理と自動化PostgreSQLの導入、監視、管理、スケーリングを行うために知っておくべきことについて学ぶホワイトペーパーをダウンロードする

PostgreSQLの主なパフォーマンス要因は何ですか

実際の実稼働環境を考えると、アプリケーションレベルのさまざまなコンポーネント、CPUやメモリなどのハードウェア、および基盤となるオペレーティングシステムと統合されています。オペレーティングシステムの上にPostgreSQLをインストールして、本番環境の他のコンポーネントと通信します。環境はそれぞれ異なり、適切に構成されていないと全体的なパフォーマンスが低下します。 PostgreSQLでは、一部のクエリは高速に実行され、一部は低速に実行されますが、設定されている構成によって異なります。データベースパフォーマンスの最適化の目標は、データベーススループットを最大化し、接続を最小化して、可能な限り最大のスループットを達成することです。以下は、データベースに影響を与えるいくつかの主要なパフォーマンス要因です。

ワークロード
リソース
最適化
競合

ワークロードは、バッチジョブ、オンライントランザクションの動的クエリ、レポートの生成に使用されるデータ分析クエリで構成されます。ワークロードは、1日、1週間、または1か月の期間で異なる場合があり、アプリケーションによって異なります。すべてのデータベースの最適化は独自のものです。これは、データベースレベルの構成またはクエリレベルの最適化にすることができます。最適化については、投稿の以降のセクションで詳しく説明します。競合とは、ワークロードの2つ以上のコンポーネントが競合する方法で単一のリソースを使用しようとしている状態です。競合が増えると、スループットが低下します。

ヒントとベストプラクティスとは

パフォーマンスの問題を回避するために従うことができるいくつかのヒントとベストプラクティスを次に示します。

データベースを大幅に変更した後、VACUUMやANALYZEなどのメンテナンスアクティビティを実行することを検討できます。これは、プランナーがクエリを実行するための最良の計画を考え出すのに役立ちます。
テーブルにインデックスを付ける必要があるかどうかを調べます。全表スキャンを実行する必要がなく、クエリの実行がはるかに高速になります。
インデックスのトラバースを大幅に高速化するには、CREATE TABLE ASまたはCLUSTERコマンドを使用して、同様のキー値を持つ行をクラスター化します。
パフォーマンスの問題が発生した場合は、EXPLAINコマンドを使用して、オプティマイザーがクエリの実行をどのように決定したかについての計画を確認します。
クエリ演算子を変更してオプティマイザに影響を与え、計画を変更してみることができます。たとえば、クエリのシーケンシャルスキャンが表示された場合は、「SETENABLE_SEQSCANTOOFF」を使用してseqスキャンを無効にできます。オプティマイザを無効にした場合、オプティマイザがその演算子を選択しないという保証はありません。オプティマイザは、オペレータがはるかに高価であると見なすだけです。詳細はこちら：https：//www.postgresql.org/docs/current/static/runtime-config-query.html
CPU_OPERATOR_COST、CPU_INDEX_TUPLE_COST、CPU_TUPLE_COST、RANDOM_PAGE_COST、EFFECTIVE_CACHE_SIZEなどのコストパラメーターを変更して、オプティマイザーに影響を与えることもできます。詳細はこちら：https：//www.postgresql.org/docs/current/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
クライアントアプリケーションではなく、常にサーバーでデータをフィルタリングします。ネットワークトラフィックを最小限に抑え、パフォーマンスを向上させます。
一般的な操作を実行するには、サーバー側の手順（トリガーと関数）を使用することを常にお勧めします。サーバー側のトリガーまたは関数は、毎回ではなく、最初に使用されるときに解析、計画、および最適化されます。

人々が犯す一般的な間違いは何ですか

人々が犯すよくある間違いの1つは、データベースサーバーとデータベースをデフォルトのパラメータで実行することです。 PostgreSQLのデフォルト構成はいくつかの環境でテストされていますが、すべてのアプリケーションがこれらの値を最適と見なすわけではありません。したがって、アプリケーションの動作を理解し、それに基づいて構成パラメーターを設定する必要があります。 pgTuneツールを使用して、使用しているハードウェアに基づいてパラメーターの値を取得できます。あなたは見ることができます：http：//pgtune.leopard.in.ua/。ただし、変更によってパフォーマンスが低下するかどうかを確認するために、行った変更を使用してアプリケーションをテストする必要があることに注意してください。

考慮すべきもう1つのことは、データベースのインデックス作成です。インデックスはデータのフェッチを高速化するのに役立ちますが、インデックスが増えるとデータの読み込みに問題が発生します。したがって、データベースに未使用のインデックスがないかどうかを常に確認し、それらを削除して、これらのインデックスのメンテナンスを減らし、データの読み込みを改善してください。