Re: Revisiting disk layout on ZFS systems

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Karl Denninger <karl(at)denninger(dot)net>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Revisiting disk layout on ZFS systems
Date: 2014-04-28 18:26:26
Message-ID: CAMkU=1zO6LQ0ESXswPeObOW0c538URd9Mw8LAtcps4qySRtWdQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Apr 28, 2014 at 11:07 AM, Karl Denninger <karl(at)denninger(dot)net> wrote:

>
> On 4/28/2014 1:04 PM, Heikki Linnakangas wrote:
>
>> On 04/28/2014 06:47 PM, Karl Denninger wrote:
>>
>>> What I am curious about, however, is the xlog -- that appears to suffer
>>> pretty badly from 128k record size, although it compresses even
>>> more-materially; 1.94x (!)
>>>
>>> The files in the xlog directory are large (16MB each) and thus "first
>>> blush" would be that having a larger record size for that storage area
>>> would help. It appears that instead it hurts.
>>>
>>
>> The WAL is fsync'd frequently. My guess is that that causes a lot of
>> extra work to repeatedly recompress the same data, or something like that.
>>
>> - Heikki
>>
>> It shouldn't as ZFS re-writes on change, and what's showing up is not
> high I/O *count* but rather percentage-busy, which implies lots of head
> movement (that is, lots of sub-allocation unit writes.)
>
> Isn't WAL essentially sequential writes during normal operation?

Only if you have some sort of non-volatile intermediary, or are willing to
risk your data integrity. Otherwise, the fsync nature trumps the
sequential nature.

Cheers,

Jeff

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Karl Denninger 2014-04-28 18:27:07 Re: Revisiting disk layout on ZFS systems
Previous Message Heikki Linnakangas 2014-04-28 18:22:36 Re: Revisiting disk layout on ZFS systems