Re: new group commit behavior not helping?
| От | Jeff Janes |
|---|---|
| Тема | Re: new group commit behavior not helping? |
| Дата | |
| Msg-id | CAMkU=1w37UVciGxTxe7S9Y3w-ft6kPm2RiMbzGaxJG3D+pdghA@mail.gmail.com обсуждение исходный текст |
| Ответ на | new group commit behavior not helping? (Robert Haas <robertmhaas@gmail.com>) |
| Список | 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 по дате отправления: