From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: new group commit behavior not helping? |
Date: | 2012-04-01 06:06:56 |
Message-ID: | CAMkU=1w37UVciGxTxe7S9Y3w-ft6kPm2RiMbzGaxJG3D+pdghA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Saturday, March 31, 2012, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Saturday, March 31, 2012, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Sun, Apr 1, 2012 at 1:40 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>
>>> It looks like in your case tps was still scaling with clients when you
gave
>>> up, so clients was probably too small.
>>
>> What is kind of weird is that it actually seems to scale at almost
>> exactly half of linear.
This is expected. A very common pattern in commits/fsync is to see
alterations between 1 and C-1, or between 2 and C-2.
To cure that, play with commit_delay. Don't make the mistake I did.
Commit_delay is in micro seconds, not ms. That didn't mater when minimum
kernel sleep was 10 or 4 ms anyway. Now with much finer sleeps, it makes a
huge difference, so try ~5000.
Cheers
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-04-01 11:07:05 | Re: measuring lwlock-related latency spikes |
Previous Message | Robert Haas | 2012-04-01 05:49:15 | Re: new group commit behavior not helping? |