これらのデータベースメンテナンスおよびチューニングの推奨設定に従ってください。
  1. データベースログのローテーションとパフォーマンス設定を構成します。
    ベストプラクティスについては、ログローテーション、ロック管理、最大同時接続数、自動バキューム設定などを参照してください。
    ディストリビューションとマネージドホスティングによって手順は異なります:
    • セルフホスト型データベース:: のデフォルトは、PostgreSQLコアディストリビューションの一般的な値です。[一部のデフォルト設定は適切ではありません] は、特に大規模な展開において、データセンターやカスタマイズされたクラウドインストール用です。
      設定を変更するには:
      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のコア配布では、デフォルトでデータベースのローカルログファイルに年齢やファイルサイズの制限はありません。ログは徐々にディスクスペースを消費します。
それを防ぐために、Syslogログ宛先へのリモートログまたはローカルログローテーションのいずれかのパラメータを構成します。
ログファイルは、年齢制限、ファイルサイズ制限、またはその両方 (いずれかが先に発生した場合) に基づいてローテーションできます。制限に達すると、その時点でファイル名パターンに一致するログファイルが存在するかどうかに応じて、PostgreSQLは新しいファイルを作成するか、既存のファイルを再利用します。再利用は、追加するか (年齢制限の場合) 上書きすることができます。
ログローテーションパラメータは次のとおりです:
  • logging_collector: データベースログを有効にするには「on」と入力してください。
  • log_filename: ログファイル名パターン。パターンは主にIEEE標準の日時フォーマットを使用します。
  • log_truncate_on_rotation: 既存のログファイルに追加するには「off」、上書きするには「on」を入力してください。これは、時間ベースのログローテーションが発生した場合にのみ適用されます。(ファイルサイズベースのログローテーションは常に追加されます。)
  • log_rotation_age: ログファイルの最大年齢 (分)。時間ベースのログローテーションを無効にするには「0」を入力してください。
  • log_rotation_size: ログファイルの最大サイズ (キロバイト (KB))。ファイルサイズに基づくログローテーションを無効にするには「0」を入力してください。

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

これらのパラメータは、1週間の各曜日ごとに1つずつ、7つのローテーションするデータベースログファイルを作成します。(ファイル名は、月曜日の場合「postgresql-Mon.log」などです。)
毎日 (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などのメンテナンス操作に使用されるメモリの最大量を決定します。

チェック項目

チェックポイントの頻度を減らします。チェックポイントは通常、データファイルへの書き込みの大部分を引き起こします。パフォーマンスを最適化するために、ほとんどのチェックポイントは「要求された」(すべての利用可能なWALセグメントを埋めるか、明示的なCHECKPOINTコマンドによってトリガーされる) ものではなく、「タイミングされた」(checkpoint_timeoutによってトリガーされる) ものであるべきです。
パラメーター名
推奨値
checkpoint_timeout
15分
checkpoint_completion_target
0.9
max_wal_size
16GB

Write-ahead log (WAL)

データベースレプリケーションを使用する場合は、wal_level = replicaを使用することを検討してください。

Autovacuum設定

PostgreSQLには「バキューム」と呼ばれる定期的なメンテナンスが必要です。通常、autovacuum_max_workersのデフォルト値を変更する必要はありません。
entitysおよびattribute2sテーブルでは、頻繁な書き込みによって多くの行が頻繁に変更される場合 (短命のクラウドインスタンスを持つ大規模なデプロイメントなど)、ディスクスペースの使用を最小限に抑え、パフォーマンスを維持するためにautovacuumをより頻繁に実行する必要があります。パラメータは、全体のデータベースとそれらの特定のテーブルの両方に設定する必要があります。
データベースレベルのパラメータ名
推奨値
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 (THP) は、より大きなメモリページを使用することで、大量のRAMを搭載したコンピュータにおけるトランスレーションルックアサイドバッファ (TLB) ルックアップのオーバーヘッドを削減するLinuxのメモリ管理システムです。デフォルトではTHPは有効になっていますが、PostgreSQLデータベースサーバーには推奨されていません。無効にするには、OSベンダーのドキュメントを参照してください。

ホストベース認証

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