Re: POC: Cache data in GetSnapshotData()

Поиск
Список
Период
Сортировка
От Mithun Cy
Тема Re: POC: Cache data in GetSnapshotData()
Дата
Msg-id CAD__OuiyXzBa9xM4OeHuEADcsLLq2fMRTNYmYn4Ufw0eWNsu8A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: POC: Cache data in GetSnapshotData()  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: POC: Cache data in GetSnapshotData()  (Mithun Cy <mithun.cy@enterprisedb.com>)
Список pgsql-hackers
Thanks Amit,
I did a quick pgbench write tests for unlogged tables at 88 clients as it had the peak performance from previous test. There is big jump in TPS due to clog changes.


clientsBASEONLY CLOG CHANGES% IncreaseONLY SAVE SNAPSHOT% IncreaseCLOG CHANGES + SAVE SNAPSHOT% Increase
8836055.42500552796.61843446.431829403437728.0041184.638911100856025.45491755.3870323515

Clients+ WITH INCREASE IN CLOG BUFFER% increase
8858217.92413861.4678626862


I will continue to benchmark above tests with much wider range of clients.


On Thu, Mar 10, 2016 at 1:36 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Mar 10, 2016 at 1:04 PM, Mithun Cy <mithun.cy@enterprisedb.com> wrote:


On Thu, Mar 3, 2016 at 11:50 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>What if you apply both this and Amit's clog control log patch(es)?  Maybe the combination of the two helps substantially more than either >one alone.


I did the above tests along with Amit's clog patch. Machine :8 socket, 64 core. 128 hyperthread.

clientsBASEONLY CLOG CHANGES% IncreaseONLY SAVE SNAPSHOT% IncreaseCLOG CHANGES + SAVE SNAPSHOT% Increase
6429247.65803430855.7288355.498118171129254.5321860.023503256232691.83277611.7758992463
8831214.30539133313.3930956.724761860632109.2486092.867093170235433.65520313.5173592978
12830896.67394934015.36215210.0939285832******34947.29635513.110221549
25627183.78092131192.89543714.7481857938******32873.78273520.9316056164

With clog changes, perf of caching the snapshot patch improves.


This data looks promising to me and indicates that saving the snapshot has benefits and we can see noticeable performance improvement especially once the CLog contention gets reduced.  I wonder if we should try these tests with unlogged tables, because I suspect most of the contention after CLogControlLock and ProcArrayLock is for WAL related locks, so you might be able to see better gain with these patches.  Do you think it makes sense to check the performance by increasing CLOG buffers (patch for same is posted in Speed up Clog thread [1]) as that also relieves contention on CLOG as per the tests I have done?





--
Thanks and Regards
Mithun C Y

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: The plan for FDW-based sharding
Следующее
От: Haribabu Kommi
Дата:
Сообщение: Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission denied”