Looked like pg_autovacuum is operating as expected. One of the annoying
limitations of pg_autovacuum in current releases is that you can't set
thresholds on a per table basis. It looks like this table might require
an even more aggressive vacuum threshold. Couple of thoughts, are you
sure
Mindaugas Riauba [EMAIL PROTECTED] writes:
And what in vacuum verbose output suggests that vacuum is not done
often enough? Current output (table is 100MB already) is below.
The output shows vacuum cleaning up about a third of the table. Usually
people like to keep the overhead down to
Mindaugas Riauba wrote:
Hello,
Our database increases in size 2.5 times during the day.
What to do to avoid this? Autovacuum running with quite
aggressive settings, FSM settings are high enough.
Database size should be more or less constant but it
has high turnover rate (100+
AFAICT the vacuum is doing what it is supposed to, and the problem has
to be just that it's not being done often enough. Which suggests either
an autovacuum bug or your autovacuum settings aren't aggressive enough.
-D -d 1 -v 1000 -V 0.5 -a 1000 -A 0.1 -s 10
That is autovacuum
Mindaugas Riauba wrote:
Might e aggressive enough, but might not. I have seen some people run
-V 0.1. Also you probably don't need -A that low. This could an issue
where analyze results in an inaccurate reltuples value which is
preventing autovacuum from doing it's job. Could you please run
Our database increases in size 2.5 times during the day.
What to do to avoid this? Autovacuum running with quite
aggressive settings, FSM settings are high enough.
First thing I'd suggest is to get a more detailed idea of exactly
what is bloating --- which tables/indexes are the
Mindaugas Riauba [EMAIL PROTECTED] writes:
First thing I'd suggest is to get a more detailed idea of exactly
what is bloating --- which tables/indexes are the problem?
I think the most problematic table is this one. After vacuum full/reindex
it was 20MB in size now (after 6 hours) it is
First thing I'd suggest is to get a more detailed idea of exactly
what is bloating --- which tables/indexes are the problem?
I think the most problematic table is this one. After vacuum
full/reindex
it was 20MB in size now (after 6 hours) it is already 70MB and counting.
AFAICT the
Mindaugas Riauba wrote:
AFAICT the vacuum is doing what it is supposed to, and the problem has
to be just that it's not being done often enough. Which suggests either
an autovacuum bug or your autovacuum settings aren't aggressive enough.
-D -d 1 -v 1000 -V 0.5 -a 1000 -A 0.1 -s 10
Mindaugas Riauba [EMAIL PROTECTED] writes:
And what in vacuum verbose output suggests that vacuum is not done
often enough? Current output (table is 100MB already) is below.
The output shows vacuum cleaning up about a third of the table. Usually
people like to keep the overhead down to 10%
Hello,
Our database increases in size 2.5 times during the day.
What to do to avoid this? Autovacuum running with quite
aggressive settings, FSM settings are high enough.
Database size should be more or less constant but it
has high turnover rate (100+ insert/update/delete per second).
Mindaugas Riauba [EMAIL PROTECTED] writes:
Our database increases in size 2.5 times during the day.
What to do to avoid this? Autovacuum running with quite
aggressive settings, FSM settings are high enough.
First thing I'd suggest is to get a more detailed idea of exactly
what is bloating
12 matches
Mail list logo
