From: | Rodrigo Barboza <rodrigombufrj(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Segment best size |
Date: | 2013-04-14 23:29:42 |
Message-ID: | CANs8QJanG+K35UHd1FSXYK69TVm3vDH61vOeYZnCYoGqVURXdg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sun, Apr 14, 2013 at 7:34 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Saturday, April 13, 2013, Rodrigo Barboza wrote:
>
>>
>>
>>
>> On Sat, Apr 13, 2013 at 4:51 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>>
>>> On Sat, Apr 13, 2013 at 10:29 AM, Rodrigo Barboza <
>>> rodrigombufrj(at)gmail(dot)com> wrote:
>>>
>>>>
>>>>
>>>> I was receiving warning messages of pgstat timeout.
>>>> I started looking for the solution for this problem and this doubt came
>>>> out.
>>>> But it doesn't seem to be the problem.
>>>>
>>>
>>> Usually that just means that you are dirtying pages faster than your
>>> hard drives can write them out, leading to IO contention. Sometimes you
>>> can do something about this by changing the work-load to dirty pages in
>>> more compact regions, or by changing the configuration. Often the only
>>> effective thing you can do is buy more hard-drives.
>>>
>>
> I meant congestion, not contention.
>
>
>>
>>>
>> Would it help if I changed the checkpoint_completion_target to something
>> close to 0.7 (mine is the default 0.5)
>>
>
> Probably not. The practical difference between 0.5 and 0.7 is so small,
> that even if it did make a difference at one place and time, it would stop
> making a difference again in the future for no apparent reason.
>
>
>> or raise the checkpoint_segments (it is 32 now)?
>>
>
> Maybe. If you are dirtying the same set of pages over and over again, and
> that set of pages fits in shared_buffers, then lengthening the time between
> checkpoints could have a good effect. Otherwise, it probably would not.
>
> Your best bet may be just to try it and see. But first, have you tried to
> tune shared_buffers?
>
> What are you doing? Bulk loading? Frantically updating a small number of
> rows?
>
> Do you have pg_xlog on a separate IO controller from the rest of the data?
> Do you have battery-backed/nonvolatile write cache?
>
> Cheers,
>
> Jeff
>
My shared_buffer is tuned for 25% of memory.
My pg_xlog is in the same device.
It is not bulk loading,
The battery I have to check, because the machine is not with me.
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Singer | 2013-04-15 00:06:42 | Re: slow bitmap heap scans on pg 9.2 |
Previous Message | Jeff Janes | 2013-04-14 22:34:40 | Re: Segment best size |