Re: Help with bad performance with synchronous commit

Поиск
Список
Период
Сортировка
От Samed YILDIRIM
Тема Re: Help with bad performance with synchronous commit
Дата
Msg-id 6346761490978204@web56g.yandex.ru
обсуждение исходный текст
Ответ на Help with bad performance with synchronous commit  ("Lazaro Garcia" <lazaro3487@gmail.com>)
Ответы Re: Help with bad performance with synchronous commit  ("Lazaro Garcia" <lazaro3487@gmail.com>)
Список pgsql-admin
Hi Lazaro,

Please initialize your test database with scale factor 50 by using pgbench than perform test again and share results to us?

Best regards.

17:45, 31 Mart 2017, Lazaro Garcia <lazaro3487@gmail.com>:

Hello everyone

 

I wite because I have a great problem and I have no idea how resolve this:

 

This is the situation:

 

I have installed a postgresql server 9.6.2 on Ubuntu server 16.04.2 LTS with this specifications:

 

12 cores y 30 GB de RAM.

 

I have created a database with pgbench for testing and the performance are very bad with  synchronous commit. These are the results:

 

scaling factor: 1

query mode: simple

number of clients: 50

number of threads: 12

duration: 30 s

number of transactions actually processed: 2773

latency average = 544.336 ms

latency stddev = 617.941 ms

tps = 91.180927 (including connections establishing)

tps = 91.194080 (excluding connections establishing)

 

By analyzing the postgres log with pgbadger I could see that the updates take a long time for a table with 10 tuples only. Then I ran a explain analyze and the explain results contradict what the test throws:

 

Update on pgbench_tellers  (cost=4.14..8.16 rows=1 width=358) (actual time=0.021..0.021 rows=0 loops=1)

   ->  Bitmap Heap Scan on pgbench_tellers  (cost=4.14..8.16 rows=1 width=358) (actual time=0.010..0.010 rows=1 loops=1)

         Recheck Cond: (tid = 5)

         Heap Blocks: exact=1

         ->  Bitmap Index Scan on pgbench_tellers_pkey  (cost=0.00..4.14 rows=1 width=0) (actual time=0.005..0.005 rows=1 loops=1)

               Index Cond: (tid = 5)

Planning time: 0.052 ms

Execution time: 0.043 ms

 

I have runned the same test in other machines with less RAM and CPU and the results are always better than this:

 

Any help to identify the problem could be very appreciated.

 

Regards

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

Предыдущее
От: "Hammerman, Joseph"
Дата:
Сообщение: Failover with a tertiary read-only secondary
Следующее
От: "Lazaro Garcia"
Дата:
Сообщение: Re: Help with bad performance with synchronous commit