Thread: maximum number of client connections?
We have the situation where it would be convenient if we could support a large number (>1024, possibly in the 2000-3000 range) of client connections. What are our options for this? Many TIA, Mark -- Mark Harrison Pixar Animation Studios Emeryville, CA
From: http://www.postgresql.org/docs/7.3/interactive/app-postmaster.html "-N max-connections Sets the maximum number of client connections that this postmaster will accept. By default, this value is 32, but it can be set as high as your system will support. (Note that -B is required to be at least twice -N. See the Administrator's Guide for a discussion of system resource requirements for large numbers of client connections.)" I hope you have lots of memory on that machine. > -----Original Message----- > From: Mark Harrison [mailto:mh@pixar.com] > Sent: Thursday, October 16, 2003 11:47 AM > To: pgsql-general@postgresql.org > Subject: [GENERAL] maximum number of client connections? > > > We have the situation where it would be convenient if we > could support a large number (>1024, possibly in the 2000-3000 > range) of client connections. > > What are our options for this? > > Many TIA, > Mark > > -- > Mark Harrison > Pixar Animation Studios > Emeryville, CA > > > ---------------------------(end of > broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to > majordomo@postgresql.org >
On Thursday 16 October 2003 11:47 am, Mark Harrison wrote: > We have the situation where it would be convenient if we > could support a large number (>1024, possibly in the 2000-3000 > range) of client connections. > > What are our options for this? I suspect your best bet is some sort of connection pooling. Even if you got PostgreSQL to compile with that many clients, each client requires a separate backend process so you would have to make sure that your OS and hardware wouldn't choke when running that many processes. I'd start by looking at SQL Relay. It seems to rate pretty well on Freshmeat and seems to have ongoing development. There's also dbBalancer. It's supposed to handle native PostgreSQL pooling but unfortunately it's still listed as "alpha" and no updates have been posted in about a year so it may be dead. If you can add a layer to your app you could try aolserver. It's high-performance, open-source and supports connection pooling out-of-the-box but would require communicating from the client side via http. There's also the connection pooling available in Java. All of this pooling talk assumes, of course, that your clients aren't so active that the pool of "real" connections becomes exhausted. Just a few places to look. Others may have ideas as well. Cheers, Steve
3000 clients = B of 6000(minimum) -> 6000 * 8KB = 48000KB 1MB = 1024KB 48000KB/(1024KB/MB) = 46.875 MB is my math right? only 47MB?? reid > -----Original Message----- > From: Dann Corbit [mailto:DCorbit@connx.com] > Sent: Thursday, October 16, 2003 3:14 PM > To: Mark Harrison > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] maximum number of client connections? > > > From: > http://www.postgresql.org/docs/7.3/interactive/app-postmaster. html "-N max-connections Sets the maximum number of client connections that this postmaster will accept. By default, this value is 32, but it can be set as high as your system will support. (Note that -B is required to be at least twice -N. See the Administrator's Guide for a discussion of system resource requirements for large numbers of client connections.)" I hope you have lots of memory on that machine. > -----Original Message----- > From: Mark Harrison [mailto:mh@pixar.com] > Sent: Thursday, October 16, 2003 11:47 AM > To: pgsql-general@postgresql.org > Subject: [GENERAL] maximum number of client connections? > > > We have the situation where it would be convenient if we could support > a large number (>1024, possibly in the 2000-3000 > range) of client connections. > > What are our options for this? > > Many TIA, > Mark > > -- > Mark Harrison > Pixar Animation Studios > Emeryville, CA > > > ---------------------------(end of > broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to > majordomo@postgresql.org > ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org