postgres stats collectorプロセスによって生成されたI / Oが多すぎます

ローカルのpostgresデータベースを持ついくつかの仮想マシンでXenServerを使用しています。すべてのアプリケーションが使用されておらず、データベースがアイドル状態の場合でも、各vmは一定のストレージネットワークトラフィックを引き起こし、iscsiストレージデバイスのパフォーマンスを低下させます。

実行後iotop、postgres stats collectorプロセスプロセスが約2 MByte / sのレートでディスクに常に書き込みを行っていることに気付きました。

次に、編集して統計の収集を無効にしました/etc/postgresql/8.4/main/postgresql.conf：

#------------------------------------------------------------------------------
# RUNTIME STATISTICS
#------------------------------------------------------------------------------

# - Query/Index Statistics Collector -

track_activities = off
track_counts = off
...

http://www.postgresql.org/docs/8.4/static/runtime-config-statistics.htmで提案されているとおり。

これは継続的な書き込みを排除しましたが、統計の追跡をオフにするデメリットはありますか？

または、ディスク/ネットワークトラフィックを回避するために、ラムディスクにpg_stat_tmpディレクトリを配置する必要がありますか？

システムは最新のDebian 6.0.7（squeeze）であり、postgres 8.4および約20のデータベースに約50のテーブルがあり、ダンプファイルの合計サイズは100 MB未満です。

PostgreSQLのアップグレードはオプションではないため、tmpfsファイルシステムにpg_stat_tmpディレクトリを配置しようとしました。これにより、パフォーマンスが大幅に向上しました。私はこれを数ダースのシステムで数ヶ月間、目立った欠点なしに実行しています。

これを行うには、/ etc / fstabファイルでtmpfsを使用してpg_stat_tmpをマウントします。

# <file system> <mount point>                                <type>  <options>  <dump>  <pass>
tmpfs           /var/lib/postgresql/8.4/main/pg_stat_tmp     tmpfs   defaults,noatime,mode=1777,uid=postgres,gid=postgres,nosuid,nodev 0 0

PostgreSQLをアップグレードします。少なくとも、最新の8.4リリースを使用していることを確認してください。それで問題が解決せず、実用的である場合は、おそらく9.2にアップグレードする必要があります。統計コレクターに関する少なくともいくつかの問題は8.4以降対処されており、約1年でサポートが終了します。pgsql-generalメーリングリストのアーカイブを検索すると、詳細情報を見つけることができる場合があります。

8.4から9.2へのアップグレードにあまり問題はないはずですが、通常は、各.0リリース（9.0、9.1、9.2）の間のリリースノートのアップグレードセクションを読む必要があります。とに特に注意しstandard_conforming_stringsてくださいbytea_output。

ここでも同じ問題。私も無効にtrack_*しています。

副作用は、autovacuumこの収集されたデータを使用して起動することです。

だから、私は毎晩のスケジュールに注意を払いvacuumdbます。

他の解決策は、autovacuum_naptimeシステムを停止させるのに十分な高さに設定することです。