Re: Tuning 8.3
От
Gregory Stark
Тема
Re: Tuning 8.3
Дата
Msg-id
87ablp3sz8.fsf@oxford.xeocode.com
Ответ на
Tuning 8.3 (Roberts, Jon)
Список
Дерево обсуждения
Tuning 8.3 "Roberts, Jon" <Jon.Roberts@asurion.com>
pgAgent job throttling "Roberts, Jon" <Jon.Roberts@asurion.com>
Re: Tuning 8.3 Andrew Dunstan <andrew@dunslane.net>
Re: Tuning 8.3 Gregory Stark <stark@enterprisedb.com>
Re: Tuning 8.3 "Roberts, Jon" <Jon.Roberts@asurion.com>
Re: Tuning 8.3 "Christopher Browne" <cbbrowne@gmail.com>
"Roberts, Jon" 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.) See: http://www.postgresql.org/docs/faqs.FAQ_windows.html#4.4 > 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 bandwidth. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
В списке pgsql-hackers по дате отправления