私がこれまでに取り組んだ
PostgreSQLドキュメントのより有用な部分の1つは、PostgreSQL
サーバーのチューニングです。それが2008年の夏に書かれたとき、PostgreSQL 8.3のリリースから数か月後、
（比較的）簡潔で最新の
同様のガイドを見つけるのは困難でした。それ以来、私と他の多くのPostgreSQL寄稿者は、PostgreSQLに変更が加えられたときに、そのドキュメントを
最新の状態に保つのに役立ってきました。
その期間中の興味深く有用な傾向は、パラメータがセットから消え続けることです
あなたが心配する必要があるものの。 PostgreSQL 8.2には、PostgreSQLサーバーで良好なパフォーマンスを実現するために調整する必要があると思われる
パラメータの長いリストがありました。
shared_buffers、effective_cache_size、
checkpoint_segments、autovacuum、max_fsm_pages、
default_statistics_target、work_mem、wal_buffers、および（
partitioningを使用している場合）constraint_exclusion。
8.3は、自動バキュームをデフォルトでオンにし、
妥当な動作でオンにし、いくつかを削除しました
問題を引き起こしただけのバックグラウンドライターパラメータ（
リストに載ることはありませんでした）。 8.4は、2つの
max_fsm_ *パラメータの必要性を取り除き、default_statistics_targetをはるかに優れた開始値に
増やし、最も一般的なケースでは、constraint_exclusionの設定を
不要にしました。これは、調整が必要になる可能性が高い
パラメータが6つ少ないことです。
残念ながら、バージョン9.0ではサーバー構成がより複雑になりました
。また、新しいLinuxカーネルは、
デフォルトの動作を逆方向にプッシュしました。 Linuxカーネル
2.6.33以降、wal_sync_methodに選択されたデフォルト値が
open_datasyncに変更されました。これは、特にサーバーのwal_buffersのデフォルト設定が低い
と組み合わせると、PostgreSQLにひどいパフォーマンスの影響を与えることがわかります。
しかし、より良いデフォルトへの行進
最近、最終的に計画されている動作が再開されました
PostgreSQL9.1。前回のCommitFest中に、wal_sync_methodの問題を修正するためのパッチがMartiから発信されました。
その変更がどのような形式をとるべきかについての激しい議論の後にコミットされました。
この動作の変更がPostgreSQLを完全に破壊したことを発見しました
br/>「data=journal」オプションを指定してext4で実行すると、
デフォルトでここで行うべき正しいことを解決するのに役立ちました。
お勧めしない2つのパラメーター
ほとんどの場合、タッチするのはcommit_siblingsとcommit_delayです。
コミット時間が遅いシステムでのパフォーマンスを改善するための古い試みの成果物（これには、その領域を高速化するための
バッテリーでバックアップされた書き込みキャッシュがないほとんどのシステムが含まれます）。現在、
8.3で導入されたsynchronous_commitパラメータをオフにすることは、
ここで役立つ可能性がはるかに高くなります。これらがパフォーマンスを向上させる可能性は低いですが、
設定しようとする人々は、その決定の欠点から
必要以上に苦しんでいます。ここでの最悪の場合の動作は、これらのパラメーターが制御するロジックの実行方法を最適化するために作成したパッチで大幅に改善されました。
そして今週、ほとんどの場合、
効果的に削除される最新のパラメーターはwal_buffersです。
提案された変更は、これをサイズのパーセンテージ（約3％）として自動的に設定するためにコミットされました。
通常ははるかに大きいshared_buffersパラメーターに割り当てられます。
これにより、wal_buffersの値が
shared_buffersに少なくとも512MBが割り当てられた場合、その有効範囲の通常の上限である16MB。また、shared_buffersをその小さなデフォルトから
少しでも増やした場合、この重要なコミットパフォーマンスパラメータで対応する改善が得られます。
以前のバージョンで発生した可能性のある悪い状況に対処するには、
このパラメータの設定を破る必要があります。
デフォルトでサーバーに対して行う必要のある構成の量を
持つことは、常に複雑さを軽減します
br />価値があり、重要なリストからパラメータが消えるのを見るのは
歓迎すべき変更です。次は何ですか？ UNIXから派生したオペレーティングシステム、特にLinuxでの
共有メモリの割り当てに関する主要な問題により、
shared_buffersを削除することが非常に困難になります。また、サーバーがシステムを引き継ぐことへの懸念が
、work_memなどのパラメータを適切な範囲に自動的に設定する機能を
制限します。
ワーキングメモリプールをより適切に管理するためのいくつかの提案があります
提案されたので、改善が見られるかもしれません。
次に注目するパラメーターは
checkpoint_segmentsです。
最後のCommitFestでこの領域にログを追加した後、この領域でいくつかの改善が行われ、実際にチェックポイントの動作を改善するために
commitに近づいています。
最終的には、ログ先行書き込みがどのように機能するかをユーザーに理解してもらうのではなく、
時間指向のパラメータを介して厳密に制御されるように、チェックポイントの調整を切り替えたいと思います。
br/>システム。ここではまだ9.1に間に合うように実行できない醜い状況が多すぎますが、セグメント数を自動的に設定することは
9.2をターゲットにするのに適しています。