5

別のプロセスによって生成され、PostgreSQL バージョン 8.4 に保存されているデータを表示する Web アプリがあります。バックエンドはかなり継続的に書き込みを行っていますが、Web アプリのビューの大部分は読み取り専用の SELECT クエリしか実行していません。

New Relic Python エージェントによると、私のビューの処理時間の 30% は COMMIT が完了するのを待つために費やされており、データを変更していない場合でも、多くの SELECT クエリを発行したビューでは特に問題があります。

読み取り専用だったトランザクションは、コミット フェーズで行う作業がほとんどないと予想していました。これらの読み取り専用クエリの COMMIT 中に Postgres は何をしているのですか?

ビューからレイテンシを隠すためにこれらのトランザクションをオフにできることはわかってsynchronous_commitいます。また、読み取り専用トランザクションの耐久性については気にしませんが、なぜそれが必要なのかがわかりません。そうすることで、より深い設定ミスが隠される可能性があります。

4

2 に答える 2

4

データベースを良好な状態に保つために実行する必要があるさまざまなクリーンアップ操作があり、これらの多くは、そのプロセスが選択クエリのみを実行している場合でも、機会に出くわした最初のプロセスによって実行されます。

これらのクリーンアップ操作は、コミット時に同期をトリガーする WAL レコードを生成できます。そのため、select はユーザーから見えるレベルでは読み取り専用かもしれませんが、実際には舞台裏で書き込みを行っています。

特定のトランザクションで実行されたすべての WAL 操作がクリーンアップ操作によるものであることを検出し、その場合は非同期で自動的にコミットできるようにする必要があります。しかし、まだ誰もこの機能を実装していません (または、このカテゴリに含まれるすべての WAL 呼び出しサイトをカタログ化することさえできていません)。

于 2013-08-09T22:07:13.803 に答える
1

コメントが短すぎるので、ここに行きます。コードの実行中にいくつかのログをキャプチャし、方程式から推測作業を取り除きます。

これらの設定が含まれるように postgresql.conf を更新します。logging_collector を取得するには、postgre を再起動する必要があります。完了したら、これらの設定を削除できますし、削除する必要があります。そのため、変更を行う前に必ず postgresql.conf をバックアップしてください。キャプチャされたデータを含むログ ファイルを取得したら、ログが 1 ページ以上のhttp://dalibo.github.io/pgbadger/である場合は、これを使用して確認することをお勧めします。

log_destination = 'stderr'
logging_collector = on
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d.log'
log_rotation_age = 0
client_min_messages = notice
log_min_messages = warning
log_min_error_statement = error
log_min_duration_statement = 0
log_checkpoints = on
log_connections = on
log_disconnections = on
log_duration = off
log_error_verbosity = verbose
log_hostname = on
log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u '
log_lock_waits = on
log_statement = 'none'
log_temp_files = 0
于 2013-08-09T21:44:17.167 に答える