本ヘルプセンターは英語版を翻訳したものです。また、一部には翻訳ソフトウエアにより機械的に翻訳した内容が含まれます。翻訳については順次対応しておりますが、最新の情報になっていない場合があります。最新の情報は英語版のページでご確認ください。表示言語は、画面右上の言語名をクリックして切り替えられます。

本ヘルプセンターの一部の記事には外部リンクが含まれています。万一リンク切れなどお気づきの点がございましたら、お手数ですが弊社サポート窓口までご連絡ください。

PostgreSQLを維持する

次のデータベース管理およびチューニングの推奨事項に従ってください。

  1. データベースログのローテーションとパフォーマンス設定を行います。

    ベストプラクティスについては、 ログローテーション, ロック管理, 最大同時接続数, 自動バキューム設定などを参照してください。

    手順は、ディストリビューションや管理対象のホスティングによって異なります。

    • 自己ホスト型データベースの場合:初期設定は、PostgreSQL Core Distributionの汎用値となります。特に大規模環境では、初期設定がデータセンターやカスタマイズされたクラウドインストールに適していないこともあります。

      設定を変更するには、次の手順に従います。

      1. プレーンテキストエディタでpostgresql.confファイルを開きます。
      2. パラメータを編集します。
      3. ファイルを保存します。
      4. PostgreSQLサービスを再起動します。
    • Amazon RDSの場合:初期設定は、インスタンスのサイズによって異なります。多くの場合、autovacuuming、 max_connections 、 effective_cache_sizeを微調整するだけです。設定を変更するには、 データベースパラメータグループ を使用し、データベースインスタンスを再起動します。
    • Amazon Auroraの場合:初期設定は、インスタンスのサイズによって異なります。多くの場合、autovacuuming、 max_connections 、 effective_cache_sizeを微調整するだけです。設定を変更するには、 データベースパラメータグループ を使用し、データベースインスタンスを再起動します。

    パフォーマンスを微調整する場合は、Amazon CloudWatchなどのサービスを使用してデータベースIOPSを監視し、設定を確認してください。

追加の支援が必要な場合は、PostgreSQLからプロフェッショナルサポートが提供されています。

ログローテーション

PostgreSQL Core Distributionの初期設定では、データベースのローカルログファイルに保持期間やファイルサイズの制限がありません。そのため、ログで消費されるディスク容量は徐々に増加していきます。

これを防ぐには、Syslogのlog_destinationへのリモートログ出力またはローカルのログローテーションについてパラメータを設定します。

ログファイルは、保持期間の制限、ファイルサイズの制限、またはその両方 (先に達した方) に基づいてローテーションされます。制限に達した場合は、その時点でファイル名のパターンに一致するログファイルが存在するかどうかに応じて、PostgreSQLでは、新しいファイルが作成されるか、既存のファイルが再利用されます。再利用の場合は、追記するか (保持期間の制限の場合は) 上書きすることができます。

ログローテーションのパラメータは次のとおりです。

  • logging_collector:データベースのログ出力を有効にするには、「on」を入力します。
  • log_filename:ログファイル名のパターン。ほとんどの場合、パターンではIEEE標準の日時形式が使用されます。
  • log_truncate_on_rotation:既存ログファイルに追記する場合は「off」、既存のログファイルを上書きする場合は「on」を入力します。適用されるのは、時間ベースのログローテーションが発生した場合のみです(ファイルサイズベースのログローテーションでは、常に追記されます)。
  • log_rotation_age:ログファイルの最大保持期間 (分)。「0」を入力すると、時間ベースのログローテーションが無効になります。
  • log_rotation_size:ログファイルの最大サイズ (KB)。「0」を入力すると、ファイルサイズベースのログローテーションが無効になります。

例:日単位のデータベースのログローテーション

以下のパラメータを使用して、ローテーションしたデータベースログファイルを7つ作成します。つまり、ファイルは各曜日に1つずつ作成されます(たとえば、月曜日のファイル名は「postgresql-Mon.log」となります)。

1 日 (1440分) ごとに、その曜日の名前が付いたファイルを作成するか (ファイルが存在しない場合)、その前の週で使用されたその曜日のログファイルを上書きします。

負荷が高い状況では、ファイルサイズの制限が無効になるため、ログ出力が「割り当てられたディスク容量を一時的に超過する」ことがあります。ただし、ファイルの数や名前は変更されません。

log_collector = on

log_filename = 'postgresql-%a.log'

log_rotation_age = 1440

log_rotation_size = 0

log_truncate_on_rotation = on

ロック管理

deadlock_timeoutの値を大きくすると、現在の環境で設定されている通常のトランザクション時間を超過することができます。

クエリによるロックの待機時間がdeadlock_timeoutの値を超えるたびに、PostgreSQLはデッドロック状態を確認し、(設定されている場合は) エラーを記録します。ところが、負荷の高い大規模環境では、多くの場合、待機時間が1秒を超えることは正常です (エラーではありません)。こうした正常なイベントが記録されると、パフォーマンスは低下します。

最大同時接続数

max_connections = 500に引き上げてください。

有効キャッシュサイズ

有効キャッシュサイズ (effective_cache_size) の値を大きくすることを検討してください。この設定は、クエリによりキャッシュの効果を推定するために使用されます。これは、クエリ計画中のコスト見積もりにのみ影響し、RAMの使用量が増加することはありません。

共有バッファ

shared_buffersの値をRAMの25%まで引き上げてください。この設定では、PostgreSQLがデータのキャッシュに使用できるメモリ容量を指定します。これによりパフォーマンスが向上します。

ワークメモリとメンテナンスワークメモリ

work_memの値を大きくしてください。この設定では、一時ディスクファイルへの書き込み前に、内部ソート操作とハッシュテーブルで使用できるRAMのサイズを指定します。複雑なクエリを実行する場合は、多くのメモリが必要になります。

maintenance_work_memの値を大きくすることを検討してください。この設定では、ALTER TABLEなどのメンテナンス操作に使用される最大メモリ容量を決定します。

チェックポイント

チェックポイントの作成頻度を減らしてください。通常は、チェックポイントにより、データファイルへの書き込みのほとんどが行われます。パフォーマンスを最適化するには、大半のチェックポイントを「requested」(使用可能なすべてのWALセグメントを入力することによるトリガ、または明示的なCHECKPOINTコマンドによるトリガ) ではなく、「timed」(checkpoint_timeoutによるトリガ) にする必要があります。

パラメータ名 推奨値
checkpoint_timeout 15min
checkpoint_completion_target 0.9
max_wal_size 16GB

ログ先行書き込み (WAL)

データベース複製を使用する場合は、wal_level = replicaを使用することを検討してください。

自動バキューム設定

PostgreSQLには、「バキューム」と呼ばれる定期的なメンテナンスが必要です。通常、autovacuum_max_workersの初期設定値を変更する必要はありません。

entitys および attribute2s 表で、頻繁な書き込みによって多くの行が頻繁に変更される場合（短時間のクラウドインスタンス), を使用する大規模な配置では、ディスク領域の使用を最小限に抑えてパフォーマンスを維持するために、自動バッファの実行頻度を増やす必要があります）。パラメータはデータベース全体と特定のテーブルの両方に設定する必要があります。

データベースレベルのパラメータ名 推奨値
autovacuum_work_mem

1GB
テーブルレベルのパラメータ名 推奨値
autovacuum_vacuum_cost_delay

10
autovacuum_vacuum_scale_factor

0.01
autovacuum_analyze_scale_factor

0.005

データベースレベルの設定を変更するには、設定ファイルまたはデータベースパラメータグループを編集し、データベースサーバを再起動する必要があります。データベースが実行されている間、コマンドはその設定を変更できません。

テーブルレベルの設定を変更するには、設定ファイルまたはデータベースパラメータグループを編集するか、次のコマンドを入力します。

ALTER TABLE public.entitys SET (autovacuum_enabled = true, autovacuum_vacuum_cost_delay = 10, autovacuum_vacuum_scale_factor = 0.01, autovacuum_analyze_scale_factor = 0.005);

ALTER TABLE public.attribute2s SET (autovacuum_enabled = true, autovacuum_vacuum_cost_delay = 10, autovacuum_vacuum_scale_factor = 0.01, autovacuum_analyze_scale_factor = 0.005);

Linux版PostgreSQL

Transparent huge pages

Transparent Huge Pages (THP) は、RAMのサイズが大きいコンピュータでより大きなメモリページを使用することにより、Translation Lookaside Buffer (TLB) 検索のオーバーヘッドを削減するLinuxのメモリ管理システムです。初期設定ではTHPが有効になっていますが、PostgreSQLデータベースサーバには推奨されていません。この機能を無効にするには、OSベンダのドキュメントを参照してください。

ホストベース認証

ホストベース認証 (HBA) により、許可されたIPアドレスの範囲に含まれていないコンピュータからデータベースへの不正アクセスを防ぐことができます。Linuxの初期設定では、データベースに対するHBAの制限はありません。ただし、通常はセキュリティグループやファイアウォールを使用することをお勧めします。