Re: posix_fadvise() and pg_receivexlog

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: didier <did447(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Mitsumasa KONDO <kondo(dot)mitsumasa(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: posix_fadvise() and pg_receivexlog
Date: 2014-09-09 13:48:05
Message-ID: CAHGQGwHhsMSxqqROA3XkUsVXXmfOcXT49YKXse=Ed3J4cezRSw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 9, 2014 at 9:07 PM, didier <did447(at)gmail(dot)com> wrote:
> Hi
>
>> Well, I'd like to hear someone from the field complaining that
>> pg_receivexlog is thrashing the cache and thus reducing the performance of
>> some other process. Or a least a synthetic test case that demonstrates that
>> happening.
> It's not with pg_receivexlog but it's related.
>
> On a small box without replication server connected perfs were good
> enough but not so with a replication server connected, there was 1GB
> worth of WAL sitting in RAM vs next to nothing without slave!

After WAL file is filled up and closed, it will not be re-read
if wal_level is set to minimal (i.e., neither archiving nor
replication is enabled). So, in this case, PostgreSQL advises the OS
to release any cached pages of that WAL file. But not if archiving
or replication is enabled, and then WAL file keeps being cached
even after it's closed. Probably this is the cause of what you
observed, I guess.

Regards,

--
Fujii Masao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-09-09 14:01:16 Re: WIP Patch for GROUPING SETS phase 1
Previous Message Fujii Masao 2014-09-09 13:17:01 Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index