web-dev-qa-db-ja.com

postgres統計収集プロセスによって生成された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と約50のテーブルを持つ約20のデータベースがあり、ダンプファイルの合計サイズは100 MB未満です。

performancepostgresqlperformance-tuningdatabase-performance
10
nn4l

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

これを行うには、/ 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
7
nn4l

ここでも同じ問題。私も無効にしましたtrack_* 等々。

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

だから、私は毎晩vacuumdbをスケジュールするように注意します。

他の解決策は、autovacuum_naptimeシステムが停止するのに十分な高さ。

0
Gelma

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には特に注意してください。

0
Craig Ringer