2

私は1つのシナリオを経験しているだけで、問題の手がかりがまったく得られていません。

名前というテーブルが1つあります（名前と時間の列があります）。このテーブルは、毎分多数の行が挿入されています。そして、これらの挿入されたレコードは、特定の時間間隔で削除されます。それで、最終的にデータの挿入を停止し、テーブルからすべての行を削除しました。

私のデータベースバージョンの詳細 

impss=# SELECT  version();
                                           version                                            
----------------------------------------------------------------------------------------------
 PostgreSQL 8.3.7 on i486-pc-linux-gnu, compiled by GCC gcc-4.3.real (Debian 4.3.2-1.1) 4.3.2
(1 row)

しかし、テーブルのサイズを見つけるためのクエリを発行すると、まだある程度のサイズが得られます。

impss=# SELECT  pg_size_pretty( pg_total_relation_size('names')) ;
 pg_size_pretty 
----------------
 1504 kB
(1 row)

最初の質問は、テーブルからすべてのレコードを削除したのに、なぜそれでもある程度のサイズが表示されるのですか。

最後の自動真空がいつ行われたかを見つけるために、私は次のクエリを発行しました：

現在の時刻は 

impss=# select now(); 
               now                
----------------------------------
 2012-11-08 20:21:10.550434+05:30
(1 row)

impss=# SELECT last_autovacuum  from pg_stat_user_tables where relname='names';
         last_autovacuum          
----------------------------------
 2012-11-08 17:51:31.995618+05:30

2番目の質問：データベースがビジー状態ではなく、このテーブルへのすべてのトランザクションをすでに停止しているにもかかわらず、この時間以降に自動バキュームプロセスが実行されなかったのはなぜですか。

したがって、レコードが削除されたときにすべてのスペースを取り戻すことができるように、頻繁にバキュームを実行するために特定の構成を行う必要があるかどうかを教えてください。

4

2 に答える 2

6

最初のクエリ - autovacuum は VACUUM FULL を呼び出さないため、リレーションのサイズには影響しません (通常、バキューム実行の瞬間にリレーションへのアクセスを求める他のリクエストがない場合、リレーション ファイルを最後から最後の生きているタプルまでトリミングできます)。 、2 番目のクエリ - autovacuum_vacuum_threshold 行が変更され、変更された行 / すべての行が autovacuum_vacuum_scale_factor よりも高い場合、自動バキュームが実行されます。これらの値は両方とも postgresql.conf にあり、デフォルト値は 50 行と 20% です。

自動バキュームの実行は、現在のデータベースの負荷には依存しません。更新/削除された行の数のみに依存します。

于 2012-11-08T18:37:17.007 に答える
2

あなたは 8.3 シリーズの非常に古いポイント リリースを使用しています。postgresql.org/support/versioning を参照してください。早急に 8.3.21 にアップグレードしてから、最新のメジャー リリースにアップグレードする準備をしてください。各メジャー リリースのリリース ノート、特に「移行」セクションをお読みください。

あなたの場合、自動バキュームは8.3以降大幅に改善されているため、バージョンが関連しています。たとえば、8.4 では、フリー スペース マップの手動管理が廃止されました。8.3 以下では、max_fsm_pages(注: 8.3 ドキュメントへの意図的なリンク)vacuumテーブル内のすべての空き領域を追跡できる十分な高さを維持する必要がありました。オーバーランすると、スペースが失われ始め、回復するためmax_fsm_pagesに を実行する必要があります。VACUUM FULLもちろん、8.3は最悪でした。遅く、後でVACUUM FULL必要になることもあったので、 .REINDEXCLUSTER

VACUUM通常、ファイルを切り捨てることができるようにタプルを移動することはありませんが、空き領域マップの問題がない新しいバージョンでは、不適切なmax_fsm_pages設定が無制限のテーブルの成長を引き起こす可能性は低くなります。安定します。

真剣に。アップグレードします。

緩和のために、ダウンタイムを計画します。ログで警告を確認し、max_fsm_pages必要に応じてそれを増やしてからCLUSTER、テーブルを増やします。これにはしばらく時間がかかることに備えてください。また、autovacuum をより積極的に実行するように調整します。

于 2012-11-09T01:37:57.993 に答える