Hi again all,

I've tested postgres 7.3.4 on Linux version 2.4.17 
and this is what I found :

The initial instance took up 8372K and this fluctuated
between +- 8372K  and 10372K, plus +- 3500K for
every connection.

I did quite a few transactions on both connections, plus
a few vacuums and a pg_dump and the total memory usage
didn't seem to go over 16M

I set all the _buffers, _mem, _fsm settings to the minimum,
restarted every time, but this had absolutely no noticeable 
increase or decrease in total memory usage.

(I used a program called gmemusage to get these stats.)

On the same machine , I tested postgres 7.1.2 with basically
the same conf options (not _fsm) and got the following :

The initial instance was 1772K and fluctuated to +- 4000K,
plus +- 3400K for every connection.

Doing the same transactions, vacuum + pg_dump, total
memory usage didn't really go over 11M, 
which was exactly what I needed. 

Although I've lived through some of the shortcomings of
7.1.2, it is still very stable, and works perfectly for
what it is going to be used for.

Again, here, I was only able to restrict things a little
by changing the configuration options, but no major
difference in memory usage.


On Mon, 6 Oct 2003 09:55:51 +0200
Stef <[EMAIL PROTECTED]> wrote:

=> Thanks for the replies,
=> On Fri, 3 Oct 2003 11:08:48 -0700
=> Josh Berkus <[EMAIL PROTECTED]> 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

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to