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

Re: Got that new server, now it's time for config!

From: Scott Mead <scott(dot)lists(at)enterprisedb(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Carlo Stonebanks <stonec(dot)register(at)sympatico(dot)ca>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Got that new server, now it's time for config!
Date: 2010-03-23 13:08:17
Message-ID: d3ab2ec81003230608y7172ef68k7c4b91442a553323@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Tue, Mar 23, 2010 at 12:12 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:

> Carlo Stonebanks wrote:
>
>> So, we have the hardware, we have the O/S - but I think our config leaves
>> much to be desired. Typically, our planner makes nad decisions, picking seq
>> scan over index scan, where index scan has a better result.
>>
>>
> You're not setting effective_cache_size, so I wouldn't expect it to ever
> choose an index scan given the size of your data set.  The planner thinks
> that anything bigger than 128MB isn't likely to fit in RAM by default, which
> favors sequential scans.  That parameter should probably be >24GB on your
> server, so it's off by more than two orders of magnitude.


+1


I'm curious why you've set:
log_min_error_statement =  debug1
log_min_messages = debug1
client_min_messages =  debug1

Although not directly addressing the problem of using index scans, this is
going to be causing lots of message verbosity, possibly (based on your rate)
enough to clobber the disks more than you need to.

-Scott M




>
>
>  wal_sync_method = open_sync
>>
>
> This is a scary setting to be playing with on Linux when using ext3
> filesystems due to general kernel bugginess in this area.  See
> http://archives.postgresql.org/pgsql-hackers/2007-10/msg01310.php for an
> example.  I wouldn't change this from the default in your position if using
> that filesystem.
>
> I'd drastically increase effective_cache_size, put wal_sync_method back to
> the default, and then see how things go for a bit before tweaking anything
> else.  Nothing else jumped out as bad in your configuration besides the
> extremely high logging levels, haven't looked at it that carefully yet
> though.
>
> --
> Greg Smith  2ndQuadrant US  Baltimore, MD
> PostgreSQL Training, Services and Support
> greg(at)2ndQuadrant(dot)com   www.2ndQuadrant.us
>
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

In response to

pgsql-performance by date

Next:From: Ross J. ReedstromDate: 2010-03-23 18:52:32
Subject: Re: mysql to postgresql, performance questions
Previous:From: Greg SmithDate: 2010-03-23 04:12:09
Subject: Re: Got that new server, now it's time for config!

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