PostgreSQLに最適な環境をセットアップする

PostgreSQLへようこそ。PostgreSQLは、小さな町の企業向けの数メガバイトの顧客データから、多国籍企業向けの数百テラバイトの「ビッグデータ」まで、あらゆるものをホストできる強力なオープンソースデータベースシステムです。アプリケーションに関係なく、データベースを実行できるようにするには、セットアップと構成のヘルプが必要になる可能性があります。

新しいサーバーがインストールされると、PostgreSQLの設定は最小限に抑えられます。これは、可能な限り最小限のハードウェアで実行するように設計されているためです。ただし、それらが最適になることはめったにありません。ここでは、新しいプロジェクトの基本的な設定と、新しいプロジェクトで最適に実行されるようにPostgreSQLを設定する方法について説明します。

ホスティング

オンプレミスホスティング

オンプレミスデータベースの場合、最適なオプションはベアメタルホストです。これは、ハイエンドのエンタープライズレベルのVMについて話している場合を除いて、仮想マシンのパフォーマンスは一般的に遅いためです。これにより、CPU、メモリ、およびディスクの設定をより厳密に制御することもできます。ただし、これには、サーバーのメンテナンスを行うための専門家（または契約）が必要です。

クラウド

クラウドでデータベースをホストすることは、ある面では素晴らしいこともあれば、他の面では悪夢になることもあります。選択したクラウドプラットフォームが高度に最適化されていない限り（通常、価格が高くなることを意味します）、負荷の高い環境では問題が発生する可能性があります。クラウドサーバーが共有されているか専用であるか（アプリケーションのサーバーからの完全なパフォーマンスを可能にする専用）、およびクラウドサーバーによって提供されるIOPS（1秒あたりの入出力操作）のレベルに注意してください。アプリケーションが成長してデータの大部分をメモリに保存できなくなる場合（またはその場合）、ディスクアクセス速度が重要になります。

一般的なホスト設定

PostgreSQLを確実にセットアップするために必要な主な柱は、ホストのCPU、メモリ、およびディスクの機能に基づいています。アプリケーションのニーズに応じて、十分なホストと適切に調整されたPostgreSQL構成が、データベースシステムのパフォーマンスに驚くべき影響を与えます。

オペレーティングシステムの選択

PostgreSQLは、ほとんどのUnixライクなオペレーティングシステムとWindowsでコンパイルできます。ただし、WindowsでのパフォーマンスはUnixライクなシステムに匹敵するものではないため、小規模な使い捨てプロジェクトでない限り、確立されたUnixライクなシステムに固執することが道のりです。この議論では、Linuxベースのシステムに固執します。

PostgreSQLのホスティングに使用されているように見える最も使用頻度の高いLinuxディストリビューションは、CentOSやScientific LinuxなどのRedHatベースのシステム、またはRedHat自体です。 Red HatとCentOSは安定性とパフォーマンスに重点を置いているため、これらのプロジェクトの背後にあるコミュニティは、データベースなどの重要なアプリケーションが可能な限り最も安全で信頼性の高いLinuxビルド上にあることを確認するために懸命に取り組んでいます。

注：LinuxにはPostgreSQLの実行に最適ではないさまざまなカーネルバージョンがあるため、可能であれば避けることを強くお勧めします（特に、ピークパフォーマンスが最も重要なアプリケーションでは）。ベンチマークは、1秒あたりのトランザクション数がカーネルバージョン3.4〜3.10から減少することを示していますが、カーネル3.12では回復し、大幅に改善されています。残念ながら、CentOSルートを使用する場合、CentOS7の使用は除外されます。 CentOS 6は引き続き有効でサポートされているオペレーティングシステムのバージョンであり、CentOS8は6がサポートされなくなる前にリリースされる予定です。

インストール

インストールは、ソースによって、または選択したLinuxのディストリビューションによって維持されているリポジトリを使用して行うことができます。さらに、Red Hatベースのシステム（Red Hat、Scientific Linux、CentOS、 Amazon Linux AMI、Oracle Enterprise Linux、Fedora）、およびDebianとUbuntuのパッケージ。 PGD​​Gパッケージを使用すると、Linuxディストリビューションの組み込みリポジトリが承認して提供するのを待つのではなく、リリース時にPostgreSQLの更新を確実に更新できるようになります。

CPU

最近では、データベースホストで複数のコアを利用できるようにすることは難しくありません。 PostgreSQL自体は、クエリレベルでマルチスレッド機能の追加を開始したばかりであり、今後数年間でさらに改善される予定です。ただし、これらの新しい今後の改善がなくても、PostgreSQL自体は、クライアントによるデータベースへの接続ごとに新しいスレッドを生成します。これらのスレッドは基本的にアクティブなときにコアを使用するため、必要なコアの数は、必要な同時接続と同時クエリのレベルによって異なります。

最初に使用するのに適したベースラインは、小規模なアプリケーション向けの4コアシステムです。アプリケーションがクエリの実行とスリープの間でダンスを行うと仮定すると、4コアシステムは過負荷になる前に数十の接続を処理できます。コアを追加すると、ワークロードの増加に合わせて拡張できます。非常に大規模なPostgreSQLデータベースに48以上のコアがあり、何百もの接続に対応できることは珍しくありません。

チューニングのヒント： ハイパースレッディングが使用可能な場合でも、ハイパースレッディングが無効になっていると、通常、1秒あたりのトランザクション数が多くなります。それほど複雑ではないが頻度が高いデータベースクエリの場合、より高速なコアよりも多くのコアが重要です。

メモリ

メモリは、PostgreSQLの全体的なパフォーマンスにとって非常に重要な側面です。メモリに関するPostgreSQLの主な設定は、shared_buffersです。これは、データキャッシュのためにPostgreSQLサーバーに直接割り当てられるメモリのチャンクです。前のセクションで説明したように、必要なデータがメモリ内に存在する可能性が高いほど、クエリがより速く返され、クエリがより高速になると、CPUコアのセットアップがより効率的になります。

また、クエリは、データがクライアントに返される前にデータの並べ替え操作を実行するためにメモリを必要とする場合があります。これは、追加のアドホックメモリ（shared_buffersとは別）を使用するか、ディスク上の一時ファイルを使用しますが、これははるかに低速です。

チューニングのヒント： shared_buffersを設定するための基本的な開始点は、使用可能なシステムRAMの値の1/4に設定することです。これにより、オペレーティングシステムは、データベース自体以外の実行中のプロセスだけでなく、独自のデータのキャッシュも実行できます。

work_memを増やすと並べ替え操作を高速化できますが、増やすと、クエリごとに値セットが部分的または完全に複数回発行される可能性があるため、ホストのメモリが不足する可能性があります。複数のクエリがソートのために複数のメモリブロックを要求する場合、ホストで使用可能なメモリよりも多くのメモリがすぐに追加される可能性があります。低く保ち、パフォーマンスが必要になるまでゆっくりと上げます。

「free」コマンド（「free-h」など）を使用して、effective_cache_sizeを、解放されてキャッシュされたメモリの合計に設定します。これにより、クエリプランナーはOSキャッシュのレベルが利用可能である可能性があることを認識し、より適切なクエリプランを実行できます。

ディスク

ディスクのパフォーマンスは、システムをセットアップするときに考慮すべき最も重要なことの1つです。入出力速度は、大量のデータをロードしたり、処理する大量のデータをフェッチしたりする場合に重要です。また、PostgreSQLがメモリをディスクと同期してメモリプールを最適に保つ速度も決定します。

ディスクでの準備は、潜在的なパフォーマンスを即座に向上させるだけでなく、データベースシステムの将来性を保証するのに役立ちます。

• 個別のディスク

  PostgreSQLを新規インストールすると、システムで使用可能なメイン（場合によっては唯一）のドライブのどこかにクラスターのデータディレクトリが作成されます。

  より多くのドライブを使用する基本的なセットアップは、別のドライブ（またはRAID経由のドライブのセット）を追加することです。これには、データベースに関連するすべてのデータ転送を、メインオペレーティングシステムとは異なるI/Oチャネルで動作させるという利点があります。また、不十分なスペースがオペレーティングシステムの他の場所で問題やエラーを引き起こすことを恐れることなく、データベースを拡張できます。

  アクティビティが極端に多いデータベースの場合、PostgreSQLトランザクションログ（xlog）ディレクトリをさらに別のドライブに配置して、メインOSおよびメインデータディレクトリから離れた別のチャネルへのより重いI/Oを分離できます。これは、システムからより多くのパフォーマンスを引き出すのに役立つ高度な手段であり、そうでなければ限界に近づく可能性があります。

• RAIDの使用

  データベースドライブにRAIDを設定すると、データの損失を防ぐだけでなく、適切なRAID構成を使用するとパフォーマンスを向上させることができます。 RAID 1または10が一般的に最適であると考えられており、10は同等性と全体的な速度を提供します。ただし、RAID 5は冗長性のレベルが高くなりますが、複数のディスクにデータを分散する方法が原因で、パフォーマンスが大幅に低下します。データを増やすための十分なスペースを備えた、利用可能な最善のオプションを計画します。これは、たとえあったとしても、頻繁に変更する必要がない構成になります。

• SSDの使用

  ソリッドステートドライブはパフォーマンスに優れており、予算を満たしていれば、エンタープライズSSDを使用すると、大量のデータ処理ワークロードを昼夜を問わず高速化できます。中小規模のワークロードを持つ中小規模のデータベースはやり過ぎかもしれませんが、大規模なアプリケーションで最小の割合の増加を目指して戦う場合、SSDはその特効薬になる可能性があります。

チューニングのヒント： 手元のアプリケーションに最適で、データが増加するにつれて時間とともに拡張できる十分なスペースがあるドライブ設定を選択しました。

SSDを使用する場合、ランダムデータフェッチは回転するディスクで見られるよりもはるかに高速であるため、random_page_costを1.5または2（デフォルトは4）に設定するとクエリプランナーにとって有益です。

初期構成設定

PostgreSQLを初めてセットアップするときは、ホストの能力に基づいて簡単に変更できるいくつかの構成設定があります。アプリケーションが時間の経過とともにデータベースにクエリを実行すると、アプリケーションのニーズに基づいて特定の調整を行うことができます。ただし、それは別のチューニングブログのトピックになります。

メモリ設定

shared_buffers：システムメモリの1/4に設定します。システムの合計メモリが1GB未満の場合は、合計システムメモリの約1/8に設定します

work_mem：デフォルトは4MBで、問題のアプリケーションには十分な場合もあります。ただし、一時ファイルが頻繁に作成され、それらのファイルがかなり小さい（数十メガバイト）場合は、この設定を上げる価値があるかもしれません。控えめなエントリレベル設定は（1/4システムメモリ/ max_connections）にすることができます。この設定は、データベースへのクエリの実際の動作と頻度に大きく依存するため、注意して増やす必要があります。問題が発生した場合は、以前のレベルに戻す準備をしてください。

Effective_cache_size：「free」コマンドによって報告された空きメモリとキャッシュメモリの合計に設定します。

チェックポイント設定

PostgreSQL 9.4以下の場合：
checkpoint_segments：先行書き込みログシステムを提供するためのいくつかのチェックポイントセグメント（それぞれ16メガバイト）。デフォルトは3で、小さなデータベースでも安全に64に増やすことができます。

PostgreSQL 9.5以降の場合：
max_wal_size：これは設定としてcheckpoint_segmentsを置き換えました。デフォルトは1GBで、さらに変更が必要になるまでここに残すことができます。

セキュリティ

listen_address：この設定は、接続をリッスンする個人のIPアドレス/ネットワークカードを決定します。単純なセットアップでは、おそらく1つしかありませんが、より高度なネットワークでは、複数のネットワークに接続するための複数のカードが必要になる場合があります。 *すべてを聞くことを意味します。ただし、データベースにアクセスするアプリケーションがデータベース自体と同じホスト上に存在する場合は、「localhost」のままにしておくだけで十分です。

ロギング

ログが過負荷にならない基本的なログ設定は次のとおりです。

log_checkpoints = on
log_connections = on
log_disconnections = on
log_temp_files = 0