Re: posix_fadvise() and pg_receivexlog - Mailing list pgsql-hackers

From didier
Subject Re: posix_fadvise() and pg_receivexlog
Date
Msg-id CAJRYxu+bJRXO7D1MtixfiRkXzpQG7gGqGUyigj1x6SQhpRM-VQ@mail.gmail.com
Whole thread Raw
In response to Re: posix_fadvise() and pg_receivexlog  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: posix_fadvise() and pg_receivexlog  (Fujii Masao <masao.fujii@gmail.com>)
Re: posix_fadvise() and pg_receivexlog  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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!
setup:
8GB RAM
2GB shared_buffers (smaller has other issues)
checkpoint_segments 40 (smaller value trigger too much xlog checkpoint)
checkpoints spread over 10 mn and write 30 to 50% of shared buffers.
live data set fit in RAM.
constant load.

On startup (1 or 2/hour) applications were running requests on cold
data which were now saturating IO.
I'm not sure it's an OS bug as the WAL were 'hotter' than the cold data.

A cron task every minute with vmtouch -e for evicting old WAL files
from memory has solved the issue.

Regards



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [TODO] Process pg_hba.conf keywords as case-insensitive
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [TODO] Process pg_hba.conf keywords as case-insensitive