| From: | Mindaugas Riauba <ml(at)kilimas(dot)com> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Linux I/O schedulers - CFQ & random seeks |
| Date: | 2011-03-08 18:27:52 |
| Message-ID: | AANLkTi=7FjA1Ljz5O3aog+5GVB448ouJ6DTyVenkt_H6@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andy Colson | 2011-03-08 19:13:38 | Re: Performance issues |
| Previous Message | Andreas Forø Tollefsen | 2011-03-08 17:00:15 | Re: Performance issues |