From: | Stef <svb(at)ucs(dot)co(dot)za> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Postgres low end processing. |
Date: | 2003-10-06 07:55:51 |
Message-ID: | 20031006095551.1d7bfeb8.svb@ucs.co.za |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
Thanks for the replies,
On Fri, 3 Oct 2003 11:08:48 -0700
Josh Berkus <josh(at)agliodbs(dot)com> wrote:
=> 1. Make sure that the WAL files (pg_xlog) are on a seperate disk from the
=> database files, either through mounting or symlinking.
I'm not sure I understand how this helps?
=> 2. Tweak the .conf file for low vacuum_mem (1024?), but vacuum very
=> frequently, like every 1-5 minutes. Spend some time tuning your
=> fsm_max_pages to the ideal level so that you're not allocating any extra
=> memory to the FSM.
=>
=> 3. If your concern is *average* CPU/RAM consumption, and not peak load
=> activity, increase wal_files and checkpoint_segments to do more efficient
=> batch processing of pending updates as the cost of some disk space. If peak
=> load activity is a problem, don't do this.
=>
=> 4. Tune all of your queries carefully to avoid anything requiring a
=> RAM-intensive merge join or CPU-eating calculated expression hash join, or
=> similar computation-or-RAM-intensive operations.
Thanks, I'll try some of these, and post the results.
The actual machines seem to be Pentium I machines,
with 32M RAM. I've gathered that it is theoretically
possible, so no to go try it.
Regards
Stef
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2003-10-06 08:13:59 | Re: Tree traversing. Like Oracle START WITH...CONNECT BY |
Previous Message | info | 2003-10-06 07:47:26 | Re: RE : RE : mod_auth_pgsql 2.0.1 don't close the backend |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff | 2003-10-06 12:07:27 | Re: reindex/vacuum locking/performance? |
Previous Message | Shridhar Daithankar | 2003-10-06 06:11:34 | Re: Postgres low end processing. |