Re: reducing the overhead of frequent table locks - now, with WIP patch

Поиск
Список
Период
Сортировка
От Jignesh Shah
Тема Re: reducing the overhead of frequent table locks - now, with WIP patch
Дата
Msg-id BANLkTik0nmy4v-zLs9OSjxXfzkpu+6UFoQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: reducing the overhead of frequent table locks - now, with WIP patch  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: reducing the overhead of frequent table locks - now, with WIP patch  (Jignesh Shah <jkshah@gmail.com>)
Список pgsql-hackers
On Mon, Jun 6, 2011 at 2:49 PM, Josh Berkus <josh@agliodbs.com> wrote:
>
>> That's an improvement of about ~3.5x.  According to the vmstat output,
>> when running without the patch, the CPU state was about 40% idle.
>> With the patch, it dropped down to around 6%.
>
> Wow!  That's fantastic.
>
> Jignesh, are you in a position to test any of Robert's work using DBT or
> other benchmarks?
>
> --
> Josh Berkus
> PostgreSQL Experts Inc.
> http://pgexperts.com
>


Okay I tried it out with sysbench read scaling test..
Note I had tried that earlier on 9.0
http://jkshah.blogspot.com/2010/11/postgresql-90-simple-select-scaling.html

And on that test I found that doing that test on anything bigger than
4 cores lead to decreased performance ..
Redoing the same test with 100 users on 4 vCPU Virtual Machine with
8GB with 1M rows I get  transactions:                        17870082 (59566.46 per sec.)
which is inline with the best number on 9.0.
This test hardly had any idle CPUs.

However where it made a huge impact was doing the same test on my 8
vCPU VM with 8GB RAM I get   transactions:                        33274594 (110914.85 per sec.)

which is a whopping 1.8x scaling for 2x scaling (from 4 to 8 vCPU)..
My idle cpu was less than 7% which when taken into consideration that
the "useful" work is line with my expectations is really impressive..
(And plus the last time I did MySQL they were around 95K or so for the
same test).

Also note that in my earlier case 60K was the max irrespective of the
hardware I threw at it.. For this fastlock patch that does not seem to
be the problem anymore :-)

This gain is impressive..

Next step DBT-2..

Regards,
Jignesh

Next step


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

Предыдущее
От: Gurjeet Singh
Дата:
Сообщение: Re: Review: psql include file using relative path
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [BUGS] BUG #6041: Unlogged table was created bad in slave node