Hello, > Once we ramped up production traffic on the machines, PostgreSQL > pretty much died under the load and could never get to a steady state. > I think this had something to do with the PG backends not having > enough I/O bandwidth (due to CFQ) to put data into cache fast enough. > This went on for an hour before we decided to switch back to deadline. > The system was back to normal working order (with 5-6x the I/O > throughput of CFQ) in about 3 minutes, after which I/O wait was down > to 0-1%. > > We run a (typical?) OLTP workload for a web app and see something like > 2000 to 5000 req/s against PG. > > Not sure if this helps in the OP's situation, but I guess it's one of > those things you need to test with a production workload to find out. > :) Me too. :) I tried switching schedulers on busy Oracle server and deadline gave +~30% in our case (against CFQ). DB was on HP EVA storage. Not 5-6 fold increase but still "free" +30% is pretty nice. CentOS 5.5. Regards, Mindaugas -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
