Skip site navigation (1) Skip section navigation (2)

Re: Problems with autovacuum

From: Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>
To: Łukasz Jagiełło <lukasz(dot)jagiello(at)gforces(dot)pl>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Problems with autovacuum
Date: 2009-05-25 21:46:11
Message-ID: 2f4958ff0905251446g6c57d28sd9dcf76445b40ba2@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
2009/5/25 Łukasz Jagiełło <lukasz(dot)jagiello(at)gforces(dot)pl>:
> W dniu 25 maja 2009 17:32 użytkownik Scott Marlowe
> <scott(dot)marlowe(at)gmail(dot)com> napisał:
>>> Recent change postgresql server from Amazon EC2 small into large one.
>>> That gives me x86_64 arch, two core cpu and 7.5GB ram. Atm got almost
>>> ~2000 small databases at that server and autovacuum working hole time
>>
>>> postgresql.conf:
>>> max_fsm_pages = 204800
>>> max_fsm_relations = 4000
>>
>> So, in 2000 databases, there's only an average of 2 relations per db
>> and 102 dead rows?  Cause that's all you got room for with those
>> settings.
>>
>> Whats the last 20 or so lines of vacuum verbose as run by a superuser say?
>
> Guess you was right
>

For future reference, if you don't log postgresql's messages, please
turn at least basic logging on, and things like that you would find in
$PGDATA/pg_log/ logs. The value suggested by postgresql, is the
minimum. I usually put in 1.5 the suggestion, which covers me from
worse case hopefully.

-- 
GJ

In response to

pgsql-performance by date

Next:From: Kenny GormanDate: 2009-05-26 15:49:25
Subject: Re: Putting tables or indexes in SSD or RAM: avoiding double caching?
Previous:From: Łukasz JagiełłoDate: 2009-05-25 19:07:53
Subject: Re: Problems with autovacuum

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group