Re: Postgres becoming slow, only full vacuum fixes it

From: Julien Cigar <jcigar(at)ulb(dot)ac(dot)be>
To: Kiriakos Tsourapas <ktsour(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgres becoming slow, only full vacuum fixes it
Date: 2012-09-24 14:14:21
Message-ID: 50606ABD.7090609@ulb.ac.be
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 09/24/2012 15:51, Kiriakos Tsourapas wrote:
> Hi,
>
> Thank you for your response.
> Please find below my answers/comments.
>
>
> On Sep 24, 2012, at 15:21, Julien Cigar wrote:
>
>> Hello,
>>
>> 1) upgrade your PostgreSQL installation, there have been numerous bugfixes releases since 8.4.2
> Not possible right now. It will have to be the last solution.
>> 2) you'll have to show us an explain analyze of the slow queries. If I take a look at those you provided everything run i less than 1ms.
> Will do so in a couple of days that it will get slow again.
>> 3) with 200 records you'll always have a seqscan
> Does it really matter? I mean, with 200 records any query should be ultra fast. Right ?

right..!

>> 4) how much memory do you have ? shared_buffers = 256MB and effective_cache_size = 512MB looks OK only if you have between 1 and 2GB of RAM
> I have included the server specs and the results of top commands, showing that we have 8GB ram and how much memory is used/cached/swapped. Personally I don't quite understand the linux memory, but I have posted them hoping you may see something I don't.

with 8GB of RAM I would start with shared_buffers to 1GB and
effective_cache_size to 4GB. I would also change the default work_mem to
32MB and maintenance_work_mem to 512MB

>> 5) synchronous_commit = off should only be used if you have a battery-backed write cache.
> I agree with the comments that have followed my post. I have changed it, knowing there is a small risk, but hoping it will help our performance.
>> 6) autovacuum_naptime should be changed only if autovacuum is constantly running (so if you have dozen of databases in your cluster)
> As I said, changing the autovacuum values have not changed the problem. So, you may as well consider that we have the default values for autovacuuming... the problem existed with the default values too.
>> 7) are you sure the problem isn't related to Bucardo ?
> Not at all sure... I have no idea. Can you suggest of a way to figure it out ?

Unfortunately I never used Bucardo, but be sure that it's not a problem
with your network (and that you understand all the challenges involved
in multi-master replication)

>
>
> Thank you

--
No trees were killed in the creation of this message.
However, many electrons were terribly inconvenienced.

Attachment Content-Type Size
jcigar.vcf text/x-vcard 292 bytes

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message henk de wit 2012-09-24 21:18:15 Spurious failure to obtain row lock possible in PG 9.1?
Previous Message Kiriakos Tsourapas 2012-09-24 13:51:44 Re: Postgres becoming slow, only full vacuum fixes it