Carl Conard wrote:
> Connections are through localhost. We've also connected via a client
> machine through a router to insure it is not something on the server.
No, I meant what client library: odbc, jdbc .net libpq?
> By drop connections, I mean Task Manager is showing additional
> postgres.exe tasks after the completion of the test. Also, when we try
> to drop the DB to reset for another test, PGAdmin reports connections.
Are you certain the application is disconnecting properly?
> Finally, of the 20 virtual users, any where from 2 to 12 or so will
> successfully complete the test (by adding information to the DB via our
> PHP app).
>
> The postmaster can be shut down manually with no issues after the test.
> However, upon rebooting the machine, I get IIS Helper Failed messages.
> I don't know if this is related or not.
OK, so you're connecting from PHP running on IIS by the sound of it.
> Logs don't really show anything. At least nothing I can find.
Are they showing connections and disconnects? If not, check you've
turned this on in your postgresql.conf
> The only changes to the config file was to enable the logging at verbose
> and info levels. I can send the file if you'd like to see it.
All you should need at the moment is connection logging and perhaps
statement logging (to see what queries get executed).
> I've noticed a number of issues about beta releases dealing with sockets
> and such. I haven't found anything indicating they were fixed or if
> there are work arounds.
It wouldn't be released if connections failed randomly. There have been
issues with network performance on Win2K machines, but that seems to be
sorted once the QoS add-on gets installed.
I think what you need is something like:
1. A copy of the PostgreSQL logs showing each connection/disconnect.
2. A log from your application code showing where it
connects/disconnects and the result codes it gets for each.
3. A count of how many connections are still present at the end of your
test.
This should fairly quickly show where the problem is. If it doesn't then
we'll need to either:
1. turn on statement logging too to see if there is a pattern.
2. Reduce the application to just connect/disconnect and see if the
probem persists.
My guess as to the source of this problem would be:
1. Application error - some code-path where a disconnect doesn't
actually happen. Because PG listens over an IP socket on Windows it'll
sit there until the connection times out.
2. Some issue with IIS/PHP running threaded and the connection library not.
--
Richard Huxton
Archonet Ltd