Re: moving pg_xlog -- yeah, it's worth it!
От | Kevin Grittner |
---|---|
Тема | Re: moving pg_xlog -- yeah, it's worth it! |
Дата | |
Msg-id | 4B73F5BB020000250002F1D5@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: moving pg_xlog -- yeah, it's worth it! (Aidan Van Dyk <aidan@highrise.ca>) |
Список | pgsql-performance |
Aidan Van Dyk <aidan@highrise.ca> wrote: > Alvaro Herrera <alvherre@commandprompt.com> wrote: >> Hmm, so maybe the performance benefit is not from it being on a >> separate array, but from it being RAID1 instead of RAID5? > > Or the cumulative effects of: > 1) Dedicated spindles/Raid1 > 2) More BBU cache available (I can't imagine the OS pair writing > much) > 3) not being queued behind data writes before getting to > controller > 3) Not waiting for BBU cache to be available (which is shared with > all data writes) which requires RAID5 writes to complete... > > Really, there's *lots* of variables here. The basics being that > WAL on the same FS as data, on a RAID5, even with BBU is worse > than WAL on a dedicated set of RAID1 spindles with it's own BBU. > > Wow! Sure, OK, but what surprised me was that a set of 15 read-only queries (with pretty random reads) took almost twice as long when the WAL files were on the same file system. That's with OS writes being only about 10% of reads, and *that's* with 128 GB of RAM which keeps a lot of the reads from having to go to the disk. I would not have expected that a read-mostly environment like this would be that sensitive to the WAL file placement. (OK, I *did* request the separate file system for them anyway, but I thought it was going to be a marginal benefit, not something this big.) -Kevin
В списке pgsql-performance по дате отправления: