Thread: Postgres performance and the Linux scheduler

On 16 June 2011 19:10, Simon Windsor <simon.windsor@cornfield.me.uk> wrote:

> Can the performance of Postgres be boosted, especially on busy systems,
>  using the none default DEADLINE Scheduler?

Probably, but it's a controversial area, and if you want to speed up a
busy system, it would be almost the last thing to look at. Changing
read-ahead settings would be almost the first thing to look at, as
ways of improving the performance of Postgres by tweaking the
operating system go. Increasing this parameter from the default is
often very effective at speeding up sequential scans.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

On 06/16/2011 02:10 PM, Simon Windsor wrote:

 

Can the performance of Postgres be boosted, especially on busy systems,  using the none default DEADLINE Scheduler?

Some system reports moderate improvements in throughput, and sometimes larger ones in worst-case latency, when switching from the default to the deadline scheduler.  Others report  best performance with the noop schedule.  Changes here are not effective in a lot of cases though.

I wrote an article for the first issue of PostgreSQL Magazine that mentions this, as the last of the most useful things you can tweak on Linux; that's available at  http://pgmag.org/

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books

Simon Windsor wrote:
> Can the performance of Postgres be boosted, especially on busy
systems,  using the none default
> DEADLINE Scheduler?

I think that mostly depends on your storage.

I personally have made one experience where (after weeks of trying
everything
else) I changed the scheduler from CFQ to deadline and immediately got
about
four times better performance. The storage in this case was a SAN.

I don't have enough experience, but my guess is that the smarter your
storage
is, the less the kernel should try to optimize I/O. I assume that in my
case
the kernel's optimizations (which try to optimize things for a physical
hard drive)
and the SAN's optimizations got in each other's way.

As I think is the case for all performance questions, there cannot be a
certain
answer -- the best thing is for you to try it out and see if it does
something for you.

Yours,
Laurenz Albe