From: | "Martin Langhoff" <martin(dot)langhoff(at)gmail(dot)com> |
---|---|
To: | "Greg Smith" <gsmith(at)gregsmith(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org, "XS Devel" <server-devel(at)lists(dot)laptop(dot)org> |
Subject: | Re: Pg 8.3 tuning recommendations for embedded low-memory device (for OLPC :-) ) |
Date: | 2008-09-15 21:43:30 |
Message-ID: | 46a038f90809151443rb4c8291i724a24ed4f818ab9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Sep 15, 2008 at 6:42 PM, Greg Smith <gsmith(at)gregsmith(dot)com> wrote:
> On Mon, 15 Sep 2008, Martin Langhoff wrote:
>
>> +max_prepared_transactions = 5
>
> That is the default on 8.3, am guessing you just uncommented it but didn't
> change. If you're not actually using prepared transactions anywhere, you
> may very well be able to drive memory use down a touch more by lowering this
> to zero.
Nothing uses prepared transactions, so I'll set it to 0.
>> +wal_writer_delay = 1000ms
>
> Presumably your goal is to lower how often transactions get written to disk
> to lower overhead, right? You mentioned in your first message you could
> handle some of that even if it's at the expense of robustness on crash. In
> that case, what you also need to set here is:
>
> synchronous_commit = off
>
> When then lets wal_writer_delay do what I think you want. See
> http://www.postgresql.org/docs/8.3/interactive/wal-async-commit.html for
> more info.
I'm somewhat hesitant on completely avoiding sync. Moodle for example
rarely writes to the DB (as most web content mgmt) except for a log
table that gets an insert per pageview. For the time being, I plan to
get _that_ insert in a async commit -- I think this will give me 99%
of the advantage, and keep the transactional sanity for the data that
matters.
Is that a reasonable approach?
> Other than that little bit of tweaking, it looks like you've got a good
> handle on the memory allocation model.
Thanks for confirming that :-)
> The other parameter you should be
> setting is effective_cache_size, to about how much total RAM is available
> for PostgreSQL to use including the OS buffer cache. That's probably at
> least 1/2 of the RAM in each system, you can look at what's leftover after
> the system is running to get a rough value there. This is only used for
> estimating what size of queries could be handled by the system, it's not a
> memory allocation.
Ok. Will set that one too.
And *thanks* -- these are great hints.
martin
--
martin(dot)langhoff(at)gmail(dot)com
martin(at)laptop(dot)org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Langhoff | 2008-09-15 21:46:58 | Re: Pg 8.3 tuning recommendations for embedded low-memory device (for OLPC :-) ) |
Previous Message | Scott Marlowe | 2008-09-15 21:40:01 | Re: Oracle and Postgresql |