Re: Revisiting disk layout on ZFS systems
| От | Jeff Janes |
|---|---|
| Тема | Re: Revisiting disk layout on ZFS systems |
| Дата | |
| Msg-id | CAMkU=1zO6LQ0ESXswPeObOW0c538URd9Mw8LAtcps4qySRtWdQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Revisiting disk layout on ZFS systems (Karl Denninger <karl@denninger.net>) |
| Ответы |
Re: Revisiting disk layout on ZFS systems
|
| Список | pgsql-performance |
On Mon, Apr 28, 2014 at 11:07 AM, Karl Denninger <karl@denninger.net> wrote:
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.)
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
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
В списке pgsql-performance по дате отправления: