開発中のRailsアプリ用にPostgreSQL9.1データベースを最適化しようとしています。postgresql.confで私は設定しました
log_min_duration_statement = 200
次に、PgBadgerを使用してログファイルを分析します。はるかに多くの時間を占めるステートメントは次のとおりです。
COMMIT;
私はこれ以上の情報を得ることができず、これがどのようなステートメントであるかについて非常に混乱しています。COMMITクエリに関するより詳細な情報を取得するために私ができることを誰かが知っていますか？他のすべてのクエリは、ステートメント、SELECT、UPDATEなどで使用される変数を表示しますが、COMMITクエリは表示しません。
@mvp が指摘しているように、すべてのトランザクション コミットは通常 fsync() 呼び出しを使用してデータをディスクにフラッシュする必要があるため、遅い場合COMMITの通常の理由は遅いs です。fsync()ただし、コミットが遅い理由はそれだけではありません。次のことが考えられます。
commit_delayます-遅延コミットが長時間実行されるステートメントとしてログに記録されることを確認していませんが、妥当なようですfsync() が遅い場合は、作業を再構築して、より少ない大きなトランザクションで実行できるようにすることをお勧めします。合理的な代替手段は、 a を使用しcommit_delayてコミットをグループ化することです。これにより、コミットがグループ化されて全体的なスループットが向上しますが、実際には個々のトランザクションが遅くなります。
さらに良いことに、問題の根本を修正します。バッテリでバックアップされたライトバック キャッシュを備えた RAID コントローラにアップグレードするか、電源フェイル セーフな高品質の SSD にアップグレードします。通常のディスクは通常、1 回転あたり 1 回未満、またはハード ドライブによっては 1 分間に 5400 ～ 15,000 回の fsync() を実行できます。大量のトランザクションと大量のコミットがあると、スループットが大幅に制限されます。これは、特に、些細なフラッシュだけを行う場合に最適なケースであるためです。対照的に、RAID コントローラーまたは SSD に永続的な書き込みキャッシュがある場合、OS はデータが実際にハード ドライブ上にあることを確認する必要はなく、データが永続的な書き込みキャッシュに到達したことを確認するだけで済みます。これは通常、電力保護された RAM に過ぎないためです。
fsync() が本当の問題ではない可能性があります。チェックポイントが遅い可能性があります。確認する最善の方法は、ログをチェックして、チェックポイントが頻繁に発生したり、時間がかかりすぎたりするという苦情がないかどうかを確認することです。log_checkpointsチェックポイントの長さと頻度を記録することもできます。
チェックポイントに時間がかかりすぎる場合は、bgwriter の完了ターゲットを調整することを検討してください (ドキュメントを参照してください)。頻度が高すぎる場合は、 を増やしcheckpoint_segmentsます。
詳細については、PostgreSQL サーバーのチューニングを参照してください。
COMMIT現在保留中のトランザクションをコミットすることを目的とする完全に有効なステートメントです。実際に行うことの性質上、データが実際にディスクにフラッシュされることを確認するため、ほとんどの時間がかかる可能性があります。
アプリの動作を高速化するにはどうすればよいですか? 現在、コードはいわゆる自動コミット モードを使用している可能性があります。つまり、すべてCOMMITのステートメントが暗黙的に実行されます。BEGIN TRANSACTION;より大きなブロックを...ブロックに明示的にラップCOMMIT;すると、アプリの動作が大幅に速くなり、コミットの数が減ります。幸運を！
数日間すべてのクエリをログに記録してから、COMMIT ステートメントの前にトランザクションで何が起こっているかを確認してください。
log_min_duration_statement = 0