Re: Linux I/O tuning: CFQ vs. deadline

From: Kevin Grittner
Subject: Re: Linux I/O tuning: CFQ vs. deadline
Date: ,
Msg-id: 4B6FD868020000250002F084@gw.wicourts.gov
(view: Whole thread, Raw)
In response to: Re: Linux I/O tuning: CFQ vs. deadline  ("Albe Laurenz")
Responses: Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith)
List: pgsql-performance

Tree view

Linux I/O tuning: CFQ vs. deadline  (Greg Smith, )
 Re: Linux I/O tuning: CFQ vs. deadline  ("Albe Laurenz", )
  Re: Linux I/O tuning: CFQ vs. deadline  ("Kevin Grittner", )
   Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith, )
    Re: Linux I/O tuning: CFQ vs. deadline  (Josh Berkus, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Scott Marlowe, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Mark Wong, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Scott Carey, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Jeff Davis, )
 Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith, )
  Re: Linux I/O tuning: CFQ vs. deadline  (, )
   Re: Linux I/O tuning: CFQ vs. deadline  (Jeff, )
    Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Scott Marlowe, )
      Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith, )
       Re: Linux I/O tuning: CFQ vs. deadline  (, )
        Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Jeff, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Scott Carey, )

"Albe Laurenz" <> wrote:
> Greg Smith wrote:

>> http://insights.oetiker.ch/linux/fsopbench/
>
> That is interesting; particularly since I have made one quite
> different experience in which deadline outperformed CFQ by a
> factor of approximately 4.

I haven't benchmarked it per se, but when we started using
PostgreSQL on Linux, the benchmarks and posts I could find
recommended deadline=elevator, so we went with that, and when the
setting was missed on a machine it was generally found fairly
quickly because people complained that the machine wasn't performing
to expectations; changing this to deadline corrected the problem.

> So I tried to look for differences, and I found two possible
> places:
> - My test case was read-only, our production system is
>   read-mostly.

Yeah, our reads are typically several times our writes -- up to
maybe 10 to 1.

> - We did not have a RAID array, but a SAN box (with RAID inside).

No SAN here, but if I recall correctly, this was mostly an issue on
our larger arrays -- RAID 5 with dozens of spindles on a BBU
hardware controller.

Other differences between our environment and that of the benchmarks
cited above:

 - We use SuSE Linux Enterprise Server, so we've been on *much*
   earlier kernel versions that this benchmark.

 - We've been using xfs, with noatime,nobarrier.

I'll keep this in mind as something to try if we have problem
performance in line with what that page describes, though....

-Kevin


pgsql-performance by date:

From: Andres Freund
Date:
Subject: Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
From: Mark Wong
Date:
Subject: Re: Linux I/O tuning: CFQ vs. deadline