Postgres - 50+ processes

Hi

A few times now, we've arrived in the morning to find Continua service unresponsive. Further investigation has shown that postgres has spawned 50+ processes. If we restart the postgres service, and then the Continua server, everything returns to normal (restarting only Postgres without restarting Continua does not work). There's nothing in the windows event log for postgres, but there are multiple continua errors of 'Timeout while getting a connection from pool.' It looks like Continua is either flooding Postgres with connection requests, or not closing old ones?

 I wish I could pinpoint the exact time this started happening, but it's a little intermittent, but at a guess it would be one of the last 2 updates before 1362.

This is on Server 2008R2 with Continua 1362. Any ideas? Any more specific and detailed info you'd like?

 Thanks

 Joel

Hi Joel

This is going to be tough to narrow down, since ADO.NET does the connection pooling under the hood. It’s not unusual to see many postgres processes, that just how it works, it originated on the unix platform where processes are more common than threads. We have certainly spent a lot of time in the past profiling the database layer and doing things like counting sessions to make sure they are being released correctly, so I’m pretty sure we are closing connections. I’ll take a look and see if there are any updates to nhibernate/postgres/postgres driver that might have any bearing on this.

Hi Joel

We spent some time looking at this yesterday, but so far have not been able to reproduce the problem. We have some debug counters that count sessions (1 db connection per session) and it doesn’t appear to be leaking sessions, and the sessions/db connections are definitely being disposed correctly.

Please try updating to the next beta build (later today) and let us know if you still see the same problem.

Hi Joel

I was able to reproduce this here tonight… something in the notifications architecture is leaking sessions. Hopefully we should be able to narrow it down tomorrow.

Thanks Vincent. We’re getting this without fail, occurring sometime between Friday close of business, and early Saturday morning (before 8am). There is nothing being triggered in that time slot that I’m aware of. The first service to complain about not getting a DB connection is the XMPP notification service, which is weird because we don’t have XMPP configured - it’s just a blank configuration as per installation defaults.

Hi Joel

Which build are you running? I believe this was fixed in the most recent beta, but I forgot to add that to the fix list.

Ah 1457. I’ll update and see how it goes this weekend. Cheers!

Just confirming 1494 has solved this issue for us. Thanks Vincent!