| From: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
|---|---|
| To: | <ktm(at)rice(dot)edu> |
| Cc: | "Jeff *EXTERN*" <jeff(at)jefftrout(dot)com>, "Jeff Janes" <jeff(dot)janes(at)gmail(dot)com>, <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Replaying 48 WAL files takes 80 minutes |
| Date: | 2012-10-30 13:16:57 |
| Message-ID: | D960CB61B694CF459DCFB4B0128514C2089A6216@exadv11.host.magwien.gv.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
ktm(at)rice(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ktm@rice.edu | 2012-10-30 13:41:24 | Re: Replaying 48 WAL files takes 80 minutes |
| Previous Message | Albe Laurenz | 2012-10-30 13:10:24 | Re: Replaying 48 WAL files takes 80 minutes |