> 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
>
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+ insert/updat
> "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
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
> >>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 a
"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:
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
Th
> >> 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.
>
>
"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)
> > 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 th
"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 bloat
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).
12 matches
Mail list logo
