Skip site navigation (1) Skip section navigation (2)

Re: Tuning 8.3

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Roberts\, Jon" <Jon(dot)Roberts(at)asurion(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Tuning 8.3
Date: 2008-02-25 16:23:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Roberts, Jon" <Jon(dot)Roberts(at)asurion(dot)com> writes:

> I need to run about 1000 PostgreSQL connections on a server that I can
> use about 4 GB of the total 16 GB of total RAM.  It seems that each
> session creates a process that uses about 15 MB of RAM just for
> connecting so I'm running out of RAM rather quickly.

I think you're being bitten by a different problem than it appears. Windows
has a fixed size per-session shared memory pool which runs out rather quickly.
You can raise that parameter though. (The 125 mentioned there is raised to
about 300 with Pg 8.3.)


> Any tips for reducing the memory footprint per session?  There is
> pgBouncer but is there anything I can do in the configuration before I
> go with a connection pooler?

I think at 1,000 you're probably into the domain where pgbouncer (or others
like it) is a good idea. Or you could pool or batch at a higher level and have
fewer sessions active at all. You don't win any performance by trying to do
more things simultaneously if they're just competing for cpu timeslices or i/o

  Gregory Stark
  Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

In response to

  • Tuning 8.3 at 2008-02-25 15:47:37 from Roberts, Jon


pgsql-hackers by date

Next:From: Roberts, JonDate: 2008-02-25 16:27:17
Subject: Re: Tuning 8.3
Previous:From: Gregory StarkDate: 2008-02-25 16:14:19
Subject: Re: Questions about indexes with text_pattern_ops

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group