Re: 9.4 regression
От | Jon Nelson |
---|---|
Тема | Re: 9.4 regression |
Дата | |
Msg-id | CAKuK5J00j4SOyE-b=k4Vx0OUZ3-U+9uBV=o-NArTW6xh43_g+w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 9.4 regression (Kevin Grittner <kgrittn@ymail.com>) |
Список | pgsql-hackers |
On Wed, Aug 7, 2013 at 4:18 PM, Kevin Grittner <kgrittn@ymail.com> wrote: > Thom Brown <thom@linux.com> wrote: > >> pgbench -j 80 -c 80 -T 3600 >> >> 269e78: 606.268013 >> 8800d8: 779.583129 I have also been running some tests and - as yet - they are inconclusive. What I can say about them so far is that - at times - they agree with these results and do show a performance hit. I took the settings as posted and adjusted them slightly for my much lower-powered personal laptop, changing checkpoint_completion_target to 1.0 and checkpoint_timeout to 1min. I am testing with the latest git HEAD, turning fallocate support on and off by editing xlog.c directly. Furthermore, before each run I would try to reduce the number of existing WAL files by making a "pre" run with checkpoint_segments = 3 before changing it to 32. For reasons I don't entirely understand, when WAL files are being created (rather than recycled) I found a performance hit, but when they were being recycled I got a slight performance gain (this may be due to reduced fragmentation) but the gain was never more than 10% and frequently less than that. I can't explain - yet (if ever!) - why my initial tests (and many of those done subsequently) showed improvement - it may very well have something to do with how the code interacts with these settings. -- Jon
В списке pgsql-hackers по дате отправления: