On Tue, Nov 30, 2010 at 10:20 AM, Craig Ringer <cr...@postnewspapers.com.au>wrote:
> On 11/30/2010 03:28 PM, Dusan Misic wrote: > >> We're having similar issues on 8.4.[245]... occasionally psql takes >> anywhere from a few to several dozen seconds to connect. I've been >> unsuccessfully trying to blame spikes in the OS run queue (we >> desperately need some connection pooling) but if it's something to >> do with locks I can't see in pg_locks, that would explain why I >> haven't been able to figure out what's going on yet.... >> -- >> Sent via pgsql-general mailing list (pgsql-general@postgresql.org >> <mailto:pgsql-general@postgresql.org>) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-general >> >> >> This is normal. PostgreSQL needs to create new server process to handle >> your requested connection. >> >> Then it needs to allocate resources to that new connection. It >> initializes shared memory for that connection. That is the stall you are >> mentioning. >> > > Eh, what? > > Forking a backend and attaching to shared memory should *not* take "a few > seconds". On my test machine it takes 100ms to fork psql, connect to the > postmaster, fork a backend, init the backend, authenticate, run a dummy > query and exit psql. > > If you're seeing delays like that, your machine is horrifyingly overloaded > or there's something else wrong. > > -- > Craig Ringer > This is not happening to me. Even on my home computer (which is terribly slow single core Sempron 2600+ with 128 kB of L2 cache, 1.5 GB DDR RAM and with slow ATA hard disks) it is fast to connect. Maximum (slowest) connection time is about 500 ms. I did some tuning in postgresql.conf. I'm very happy with PostgreSQL speed on my 'snail' computer. :)
