Re: new group commit behavior not helping? - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: new group commit behavior not helping?
Date
Msg-id CAMkU=1w37UVciGxTxe7S9Y3w-ft6kPm2RiMbzGaxJG3D+pdghA@mail.gmail.com
Whole thread Raw
In response to new group commit behavior not helping?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Saturday, March 31, 2012, Jeff Janes <<a href="mailto:jeff.janes@gmail.com">jeff.janes@gmail.com</a>>
wrote:<br/>> On Saturday, March 31, 2012, Robert Haas <<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>wrote:<br /> >> On Sun, Apr 1, 2012 at 1:40 AM,
JeffJanes <<a href="mailto:jeff.janes@gmail.com">jeff.janes@gmail.com</a>> wrote:<br />><br />>>> It
lookslike in your case tps was still scaling with clients when you gave<br /> >>> up, so clients was probably
toosmall.<br />>><br />>> What is kind of weird is that it actually seems to scale at almost<br />>>
exactlyhalf of linear.  <br /><br />This is expected.  A very common pattern in commits/fsync is to see alterations
between1 and C-1,  or between 2 and C-2.<br /><br />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
withmuch finer sleeps, it makes a huge difference, so try ~5000.<br /><br />Cheers <br /><br />Jeff  

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: new group commit behavior not helping?
Next
From: Simon Riggs
Date:
Subject: Re: measuring lwlock-related latency spikes