Re: WIP: dynahash replacement for buffer table
| От | Amit Kapila |
|---|---|
| Тема | Re: WIP: dynahash replacement for buffer table |
| Дата | |
| Msg-id | CAA4eK1Jz7wVsXe3M3qV_5tmRfT18AmD06T9NgKHFwVBNH3LcgA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: WIP: dynahash replacement for buffer table (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
On Tue, Jan 27, 2015 at 9:50 AM, Robert Haas <robertmhaas@gmail.com> wrote:
Configuration and Db Details
----------------------------------------------
IBM POWER-8 24 cores, 192 hardware threads
RAM = 492GB
checkpoint_segments=300
checkpoint_timeout =25min
Client Count = number of concurrent sessions and threads (ex. -c 8 -j 8)
Duration of each individual run = 5min
Scale_factor - 5000
HEAD (commit id - 168a809d)
Shared_buffers=8GB
This developed a slight merge conflict. I've rebased the attached
version, and I also took the step of getting rid of buf_table.c, as I
think I proposed somewhere upthread. This avoids the overhead of
constructing a BufferTag only to copy it into a BufferLookupEnt, plus
some function calls and so forth. A quick-and-dirty test suggests
this might not have cut down on the 1-client overhead much, but I
think it's worth doing anyway: it's certainly saving a few cycles, and
I don't think it's complicating anything measurably.
Performance data at some of the configurations.
----------------------------------------------
IBM POWER-8 24 cores, 192 hardware threads
RAM = 492GB
checkpoint_segments=300
checkpoint_timeout =25min
Client Count = number of concurrent sessions and threads (ex. -c 8 -j 8)
Duration of each individual run = 5min
Scale_factor - 5000
HEAD (commit id - 168a809d)
Below is the data for median of 3-runs with pgbench read-only
(using -M prepared) configuration
| Client Count/No. Of Runs (tps) | 1 | 8 | 16 | 32 | 64 | 128 | 256 |
| HEAD | 17748 | 119106 | 164949 | 246632 | 216763 | 183177 | 173055 |
| HEAD + patch | 17802 | 119721 | 167422 | 298746 | 457863 | 422621 | 356756 |
| Client Count/No. Of Runs (tps) | 1 | 8 | 16 | 32 | 64 | 128 | 256 |
| HEAD | 18139 | 113265 | 169217 | 270172 | 310936 | 238490 | 215308 |
| HEAD + patch | 17900 | 119960 | 174196 | 314866 | 448238 | 425916 | 347919 |
Observations as per data
--------------------------------------
a. It improves the tps by great margin at higher client count.
b. It is evident that as we increase the shared buffers, the gain
is relatively less (gain when shared_buffers is 16GB is lesser as
compare to when shared_buffers is 8GB)
I think the patch is valuable for such loads even though it will show
lesser benefit at higher shared buffers value, although we might want
to once verify that it doesn't topple at configurations such as
(shared_buffers = scale_factor).
В списке pgsql-hackers по дате отправления: