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
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 |