Re: Perf regression in 2.6.32 (Ubuntu 10.04 LTS)

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Perf regression in 2.6.32 (Ubuntu 10.04 LTS)
Дата
Msg-id 4C8E4BCA.3040003@2ndquadrant.com
обсуждение исходный текст
Ответ на Perf regression in 2.6.32 (Ubuntu 10.04 LTS)  (Domas Mituzas <midom.lists@gmail.com>)
Ответы Re: Perf regression in 2.6.32 (Ubuntu 10.04 LTS)  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Re: Perf regression in 2.6.32 (Ubuntu 10.04 LTS)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Domas Mituzas wrote:
> I've been playing around today a lot with sysbench, and observed that 2.6.32 kernel supplied by Ubuntu is having perf
regressionwith PG (which does not affect MySQL), compared to 2.6.28 builds I have.
 
> What I observed can be seen in a paste at http://p.defau.lt/?8_GQV82Pz3_SDZbNOdP93Q (db12 is 2.6.28, db20 is 2.6.32 -
2.6.32-24-server).
 
>
> Machines are two socket quad-opterons 2356s. 
>
> oprofile output can be seen at http://p.defau.lt/?OIR1vDFK4cze_fmBTQbV9w - system has >20% of idle cpu, which is
somewherein the top symbol :)
 
>   

Are you using the same filesystem setup on both setups?  And regardless, 
what is that filesystem?  We know that between 2.6.28 and 2.6.32 the 
kernel improved how it handles fsync requests in a good way from a 
reliability perspective (to fix bugs that could cause data loss before), 
particularly on ext4, so it's possible the regression you're seeing is 
just the expense of handling things properly.

If you already have sysbench on there, I'd suggest comparing the two 
systems by seeing how fast each can execute fsync requests:

sysbench --test=fileio --file-fsync-freq=1 --file-num=1 
--file-total-size=16384 --file-test-mode=rndwr run | grep "Requests/sec"

To help distinguish whether this regression might be coming from the 
already known changes in that area, or if it's instead from something 
that's impacting CPU efficiency.

Also, it's easy to see a performance change of this size just from the 
database files being on a different part of the disk if you didn't 
control for that.  Disks are almost twice as fast at their beginning 
than their end nowadays.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: cvs2git reports a "sprout" from a nonexistent commit?
Следующее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: Perf regression in 2.6.32 (Ubuntu 10.04 LTS)