Gavin Flower wrote: >> We found that the real-world production performance of a web >> application servicing millions of we hits per day with thousands >> of concurrent users improved when we reconfigured our database >> connection pool to be about 35 instead of 55, on a 16 core box >> with a 40 drive RAID. > Curious, what is your RAID configuration? We have the OS on RAID 1 on one RAID controller, WAL on another RAID 1 array on its own controller, and the PostgreSQL data directory on RAID 5 on a pair of controllers which each has a path to every drive. (Don't ask me how that works, I just trust the hardware guys to get that part right.) The active portion of the database is cached, the read-to-write ratio is about 10 to 1, and the controllers all have BBU cache with write-back. It is actually one pool of about 30 for the read-only web app with so many hits, and a separate pool of 6 database connections for logical replication from about 80 source databases handling an OLTP load of 3000 directly connected users. We were seeing some performance degradation at peak loads, and improved both user response time and overall throughput by reducing the database connections used by the connection pool. Peak load was handled much better that way. I cringe every time I see someone say they need a large number of database connections in order to support that many users. Having one database connection for each user is, in my experience, guaranteed to make things fall apart under load. -Kevin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
