On Wed, July 18, 2007 01:56, Fei Liu wrote: > It appears my multi-thread application (100 connections every 5 seconds) > is stalled when working with postgresql database server. I have limited > number of connections in my connection pool to postgresql to 20. At the > begining, connection is allocated and released from connection pool as > postgres serves data request. The pool can recover from exhaustion. But > very quickly (after about 400 client requests), it seems postgres server > stops serving and connection to postgres server is not released any more > resulting a resource exhausting for clients.
It looks like either your threads get "stuck" somehow, or your code leaks connections. In this case you can check for leaks by allowing fewer threads than you have connections. If you still run out of connections in your pool, the problem is that some threads complete their work without releasing their connections to the pool. If the program simply stops, then the problem is that the threads get stuck. In the latter case, try to figure out where they get stuck. One way of doing that is by using a debugger; another is to add some instrumentation code to each thread that opens a file and writes log information to it. > I am using a slightly model to protect thread generation. I have another > thread pool that limits number of concurrent threads to about 30. I have > enclosed my wrapper interface to libpqxx. Maybe I did something wrong > with my wrapper? My client code uses strictly the transactor interface. > What's the implementation strategy of pqxx::transactor<> ? That really shouldn't make a difference, since it doesn't affect the connection. The implementation for transactor execution (the code for pqxx::connection_base::perform(), which is an inline template function) is in include/pqxx/transactor.hxx. As you can see there, it starts a transaction, executes your transactor, and tries to commit. Apart from transparent re-connection when needed and allowed, this shouldn't really affect the lifetime of the connection. Jeroen _______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
