From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Marcus Engene <mengpg2(at)engene(dot)se> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: WAL in RAM |
Date: | 2011-10-28 19:09:04 |
Message-ID: | CAGTBQpacH8b47YWOCDJqBF06LWB-XGVdAzEiXG42v8WWvO8+Bg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, Oct 28, 2011 at 12:28 PM, Marcus Engene <mengpg2(at)engene(dot)se> wrote:
> Hi list,
>
> Every now and then I have write peaks which causes annoying delay on my
> website. No particular reason it seems, just that laws of probability
> dictates that there will be peaks every now and then.
>
> Anyway, thinking of ways to make the peaks more bareable, I saw the new 9.1
> feature to bypass WAL. Problems is mainly that some statistics tables ("x
> users clicked this link this month") clog the write cache, not more
> important writes. I could live with restoring a nightly dump of these tables
> and loose a days worth of logs.
> ...
> Does anyone here have any recommendations here?
You didn't post configuration details.
Just OTOMH, I'd say you have a low shared_buffers setting and that
increasing it could help.
That's assuming the updates you mention on statistic tables update
heavily the same rows over and over, case in which shared buffers
would tremendously help.
From | Date | Subject | |
---|---|---|---|
Next Message | David Boreham | 2011-10-28 19:55:49 | Re: WAL in RAM |
Previous Message | Tomas Vondra | 2011-10-28 19:07:44 | Re: WAL in RAM |