Re: Replaying 48 WAL files takes 80 minutes
| От | ktm@rice.edu |
|---|---|
| Тема | Re: Replaying 48 WAL files takes 80 minutes |
| Дата | |
| Msg-id | 20121030134124.GL2872@aart.rice.edu обсуждение |
| Ответ на | Re: Replaying 48 WAL files takes 80 minutes ("Albe Laurenz" <laurenz.albe@wien.gv.at>) |
| Список | pgsql-performance |
On Tue, Oct 30, 2012 at 02:16:57PM +0100, Albe Laurenz wrote: > ktm@rice.edu wrote: > >>> If you do not have good random io performance log replay is nearly > >>> unbearable. > >>> > >>> also, what io scheduler are you using? if it is cfq change that to > >>> deadline or noop. > >>> that can make a huge difference. > >> > >> We use the noop scheduler. > >> As I said, an identical system performed well in load tests. > > > The load tests probably had the "important" data already cached. > Processing > > a WAL file would involve bringing all the data back into memory using > a > > random I/O pattern. > > The database is way too big (1 TB) to fit into cache. > > What are "all the data" that have to be brought back? > Surely only the database blocks that are modified by the WAL, > right? > > Yours, > Laurenz Albe > Right, it would only read the blocks that are modified. Regards, Ken
В списке pgsql-performance по дате отправления: