Re: Replaying 48 WAL files takes 80 minutes - Mailing list pgsql-performance

From Albe Laurenz
Subject Re: Replaying 48 WAL files takes 80 minutes
Date
Msg-id D960CB61B694CF459DCFB4B0128514C2089A6216@exadv11.host.magwien.gv.at
Whole thread Raw
In response to Re: Replaying 48 WAL files takes 80 minutes  ("ktm@rice.edu" <ktm@rice.edu>)
Responses Re: Replaying 48 WAL files takes 80 minutes  ("ktm@rice.edu" <ktm@rice.edu>)
List pgsql-performance
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


pgsql-performance by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Re: Replaying 48 WAL files takes 80 minutes
Next
From: "ktm@rice.edu"
Date:
Subject: Re: Replaying 48 WAL files takes 80 minutes