From: Michael Stone
Subject: Re: PG8 Tuning
Date: ,
Msg-id: 20050811235444.GO19080@mathom.us
(view: Whole thread, Raw)
In response to: Re: PG8 Tuning  (Mark Lewis)
List: pgsql-performance

Tree view

PG8 Tuning  ("Paul Johnson", )
 Re: PG8 Tuning  (Richard Huxton, )
 [SPAM?] Re: PG8 Tuning  (Steve Poe, )
  Re: [SPAM?] Re: PG8 Tuning  ("Jeffrey W. Baker", )
   Re: [SPAM?] Re: PG8 Tuning  (Jeff Trout, )
   Re: [SPAM?] Re: PG8 Tuning  (Josh Berkus, )
    Re: [SPAM?] Re: PG8 Tuning  (Alvaro Herrera <-ip.org>, )
     Re: [SPAM?] Re: PG8 Tuning  ("Joshua D. Drake", )
     Re: PG8 Tuning  (John A Meinel, )
      Re: PG8 Tuning  (Tom Lane, )
       Re: PG8 Tuning  (John A Meinel, )
        Re: PG8 Tuning  (Tom Lane, )
    Re: [SPAM?] Re: PG8 Tuning  (Michael Stone, )
     Re: PG8 Tuning  (Josh Berkus, )
  Re: [SPAM?] Re: PG8 Tuning  (Tom Arthurs, )
  Re: PG8 Tuning  (Mark Lewis, )
   Re: PG8 Tuning  (Michael Stone, )
 Re: PG8 Tuning  (Michael Stone, )
 Re: PG8 Tuning  ("Merlin Moncure", )

On Thu, Aug 11, 2005 at 10:18:44AM -0700, Mark Lewis wrote:
>Actually, it seems to me that with the addition of the WAL in PostgreSQL
>and the subsequent decreased need to fsync the data files themselves
>(only during checkpoints?), that the only time a battery-backed write
>cache would make a really large performance difference would be on the
>drive(s) hosting the WAL.

Write cache on a raid array helps in the general case too, because
it allows the controller to aggregate & reorder write requests. The OS
probably tries to do this to some degree, but it can't do as well as the
raid controller because it doesn't know the physical disk layout.

>Hmmm, on second thought, now I think I understand the rationale behind
>having a non-zero commit delay setting-- the problem with putting
>pg_xlog on a single disk without a write cache is that frequent fsync()
>calls might cause it to spend most of its time seeking instead of
>writing (as seems to be happening to Paul here).  Then again, the OS IO
>scheduler should take care of this for you, making this a non-issue.

The OS can't do anything much in terms of IO scheduling for synchronous
writes. Either it handles them in suboptimal order or you get hideous
latency while requests are queued for reordering. Neither option is
really great.

Mike Stone


pgsql-performance by date:

From: Michael Stone
Date:
Subject: Re: Mostly read performance
From: Greg Stark
Date:
Subject: Re: Mostly read performance