From: | Guy Rouillier <guyr-ml1(at)burntmail(dot)com> |
---|---|
To: | PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: High update activity, PostgreSQL vs BigDBMS |
Date: | 2007-01-07 04:32:59 |
Message-ID: | 45A077FB.3010802@burntmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Dave Cramer wrote:
>>
>> The box has 3 GB of memory. I would think that BigDBMS would be hurt
>> by this more than PG. Here are the settings I've modified in
>> postgresql.conf:
>
> As I said you need to set shared_buffers to at least 750MB this is the
> starting point, it can actually go higher. Additionally effective cache
> should be set to 2.25 G turning fsync is not a real world situation.
> Additional tuning of file systems can provide some gain, however as
> Craig pointed out some queries may need to be tweaked.
Dave, thanks for the hard numbers, I'll try them. I agree turning fsync
off is not a production option. In another reply to my original
posting, Alex mentioned that BigDBMS gets an advantage from its async
IO. So simply as a test, I turned fsync off in an attempt to open wide
all the pipes.
Regarding shared_buffers=750MB, the last discussions I remember on this
subject said that anything over 10,000 (8K buffers = 80 MB) had unproven
benefits. So I'm surprised to see such a large value suggested. I'll
certainly give it a try and see what happens.
>>
>> autovacuum=on
>> stats_row_level = on
>> max_connections = 10
>> listen_addresses = 'db01,localhost'
>> shared_buffers = 128MB
>> work_mem = 16MB
>> maintenance_work_mem = 64MB
>> temp_buffers = 32MB
>> max_fsm_pages = 204800
>> checkpoint_segments = 30
>> redirect_stderr = on
>> log_line_prefix = '%t %d'
--
Guy Rouillier
From | Date | Subject | |
---|---|---|---|
Next Message | Colin Taylor | 2007-01-07 04:37:08 | table partioning performance |
Previous Message | Guy Rouillier | 2007-01-07 04:22:58 | Re: High update activity, PostgreSQL vs BigDBMS |