John R Pierce > On 07/03/12 12:34 AM, Craig Ringer wrote: >> I'm seriously impressed that your system is working under load at >> all with 800 concurrent connections fighting to write all at once. > > indeed, in my transactional benchmarks on a 12 core, 24 thread dual > xeon x5600 class systems, with 16 or 20 spindle raid10, I find > somewherre around 50 to 80 database connection threads has the > highest overall throughput (several thousand OLTP > transactions/second). this hardware has vastly better IO and CPU > performance than any AWS virtual machine. > > > as craig suggested, your network threads could put the incoming > requests into queue(s), and run a tunable number of database > connection threads that take requests out of the queue and send > them to the database, and if neccessary, return results to the > network thread. doing this will give better CPU utilization, you > can try different database worker thread counts til you hit the > optimal number for your hardware. +1 We (at the Wisconsin courts) have definitely found that the best model for us is to have a separate layer for running database transactions, with one thread per database connection and each of those threads pulling from a prioritized FIFO queue into which *other* layers place requests. This comes up so often that I threw together a Wiki page for it: http://wiki.postgresql.org/wiki/Number_Of_Database_Connections Of course, everyone should feel free to improve the page. -Kevin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
