Re: Strange behavior: pgbench and new Linux kernels
От | david@lang.hm |
---|---|
Тема | Re: Strange behavior: pgbench and new Linux kernels |
Дата | |
Msg-id | alpine.DEB.1.10.0804171740250.18186@asgard обсуждение исходный текст |
Ответ на | Re: Strange behavior: pgbench and new Linux kernels (Greg Smith <gsmith@gregsmith.com>) |
Ответы |
Re: Strange behavior: pgbench and new Linux kernels
|
Список | pgsql-performance |
On Thu, 17 Apr 2008, Greg Smith wrote: > On Thu, 17 Apr 2008, Matthew wrote: > >> The last message in the thread says that 2.6.25-rc6 has the problem nailed. >> That was a month ago. So I guess, upgrade to 2.6.25, which was released >> today. > > Ah, even more support for me to distrust everything I read. The change has > flattened out things, so now the pgbench results are awful everywhere. On > this benchmark 2.6.25 is the worst kernel yet: > > -bash-3.00$ pgbench -S -c 4 -t 10000 pgbench | grep excluding > tps = 8619.710649 (excluding connections establishing) > tps = 8664.321235 (excluding connections establishing) > tps = 8671.973915 (excluding connections establishing) > (was 18388 in 2.6.9 and 16621 in 2.6.23-3) > > -bash-3.00$ pgbench -S -c 8 -t 10000 pgbench | grep excluding > tps = 9011.728765 (excluding connections establishing) > tps = 9039.441796 (excluding connections establishing) > tps = 9206.574000 (excluding connections establishing) > (was 15760 in 2.6.9 and 15551 in 2.6.23-3) > > -bash-3.00$ pgbench -S -c 16 -t 10000 pgbench | grep excluding > tps = 7063.710786 (excluding connections establishing) > tps = 6956.266777 (excluding connections establishing) > tps = 7120.971600 (excluding connections establishing) > (was 14148 in 2.6.9 and 7311 in 2.6.23-3) > > -bash-3.00$ pgbench -S -c 32 -t 10000 pgbench | grep excluding > tps = 7006.311636 (excluding connections establishing) > tps = 6971.305909 (excluding connections establishing) > tps = 7002.820583 (excluding connections establishing) > (was 13647 in 2.6.9 and 7141 in 2.6.23-3) > > This is what happens when the kernel developers are using results from a > MySQL tool to optimize things I guess. It seems I have a lot of work ahead > of me here to nail down and report what's going on here. report this to the kernel list so that they know, and be ready to test fixes. the kernel developers base sucess or failure on the results of tests. if the only people providing test results are MySQL people, how would they know there is a problem? David Lang
В списке pgsql-performance по дате отправления: