Re: Postgres low end processing. - Mailing list pgsql-performance

From Josh Berkus
Subject Re: Postgres low end processing.
Date
Msg-id 200310031108.49002.josh@agliodbs.com
Whole thread Raw
In response to Postgres low end processing.  (Stef <svb@ucs.co.za>)
Responses Re: Postgres low end processing.
Re: Postgres low end processing.
List pgsql-performance
Stef,

> I've been trying to find out if some guidelines
> exist, somewhere, describing how postgres
> can possibly run on less than 8MB of RAM.
> (Disk space not an issue).

I can tell you from experience that you will get some odd behaviour, and even
connection failures, when Postgres is forced into swap by lack of memory.
Also, you will run into trouble with the default Linux kernel 2.4 VM manager,
which allows applications to overcommit memory; either hack your own memory
manager, or designate swap space >= 200% of RAM.

Also, program your application to expect, and recover from, PostgreSQL
failures and connection failures.

> Is it possible to have a stripped-down version of
> postgres that will use an absolute minimal amount
> of memory?

I don;t know that there is anything you can remove safely from the postgres
core that would save you memory.

> Maybe by switching off some features/options
> at compile time, and/or configuration tweaks?
> (Or anything else)

You're in luck; the default postgresql.conf file for 7.3 is actually cofigured
for a low-memory, slow machine setup (which most other people bitch about).
Here's a few other things you can do:

1. Make sure that the WAL files (pg_xlog) are on a seperate disk from the
database files, either through mounting or symlinking.

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.

--
Josh Berkus
Aglio Database Solutions
San Francisco

pgsql-performance by date:

Previous
From: Oleg Lebedev
Date:
Subject: Re: TPC-R benchmarks
Next
From: Ron Johnson
Date:
Subject: Re: Postgres low end processing.