Re: Scaling shared buffer eviction
От | Amit Kapila |
---|---|
Тема | Re: Scaling shared buffer eviction |
Дата | |
Msg-id | CAA4eK1KX1Jz87WFzYipjwx=GhUL2k3ZK2j=gkYztu3m_5kkAMw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Scaling shared buffer eviction (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
On Tue, Oct 14, 2014 at 3:32 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-10-14 15:24:57 +0530, Amit Kapila wrote:
> > After that I observed that contention for LW_SHARED has reduced
> > for this load, but it didn't help much in terms of performance, so I again
> > rechecked the profile and this time most of the contention is moved
> > to spinlock used in dynahash for buf mapping tables, please refer
> > the profile (for 128 client count; Read only load) below:
> >
> > bgreclaimer patch + wait free lw_shared acquisition patches -
> > ------------------------------------------------------------------------------------------
>
> This profile is without -O2 again. I really don't think it makes much
> sense to draw much inference from an unoptimized build.
> On 2014-10-14 15:24:57 +0530, Amit Kapila wrote:
> > After that I observed that contention for LW_SHARED has reduced
> > for this load, but it didn't help much in terms of performance, so I again
> > rechecked the profile and this time most of the contention is moved
> > to spinlock used in dynahash for buf mapping tables, please refer
> > the profile (for 128 client count; Read only load) below:
> >
> > bgreclaimer patch + wait free lw_shared acquisition patches -
> > ------------------------------------------------------------------------------------------
>
> This profile is without -O2 again. I really don't think it makes much
> sense to draw much inference from an unoptimized build.
Profile data with -O2 is below. This shows that top
contributors are calls for BufTableLookup and spin lock caused
by BufTableInsert and BufTableDelete. To resolve spin lock
contention, patch like above might prove to be useful (although
I have to still evaluate the same). I would like to once take
LWLOCK_STATS data as well before proceeding further.
Do you have any other ideas?
11.17% swapper [unknown] [H] 0x00000000011e0328
+ 4.62% postgres postgres [.] hash_search_with_hash_value
+ 4.35% pgbench [kernel.kallsyms] [k] .find_busiest_group
+ 3.71% postgres postgres [.] s_lock
2.56% postgres [unknown] [H] 0x0000000001500120
+ 2.23% pgbench [kernel.kallsyms] [k] .idle_cpu
+ 1.97% postgres postgres [.] LWLockAttemptLock
+ 1.73% postgres postgres [.] LWLockRelease
+ 1.47% postgres [kernel.kallsyms] [k] .__copy_tofrom_user_power7
+ 1.44% postgres postgres [.] GetSnapshotData
+ 1.28% postgres postgres [.] _bt_compare
+ 1.04% swapper [kernel.kallsyms] [k] .int_sqrt
+ 1.04% postgres postgres [.] AllocSetAlloc
+ 0.97% pgbench [kernel.kallsyms] [k] .default_wake_function
Detailed Data
----------------
- 4.62% postgres postgres [.] hash_search_with_hash_value
- hash_search_with_hash_value
- 2.19% BufTableLookup
- 2.15% BufTableLookup
ReadBuffer_common
- ReadBufferExtended
- 1.32% _bt_relandgetbuf
- 0.73% BufTableDelete
- 0.71% BufTableDelete
ReadBuffer_common
ReadBufferExtended
- 0.69% BufTableInsert
- 0.68% BufTableInsert
ReadBuffer_common
ReadBufferExtended
0.66% hash_search_with_hash_value
- 4.35% pgbench [kernel.kallsyms] [k] .find_busiest_group
- .find_busiest_group
- 4.28% .find_busiest_group
- 4.26% .load_balance
- 4.26% .idle_balance
- .__schedule
- 4.26% .schedule_hrtimeout_range_clock
.do_select
.core_sys_select
- 3.71% postgres postgres [.] s_lock
- s_lock
- 3.19% hash_search_with_hash_value
- 3.18% hash_search_with_hash_value
- 1.60% BufTableInsert
ReadBuffer_common
- ReadBufferExtended
- 1.57% BufTableDelete
ReadBuffer_common
- ReadBufferExtended
- 0.93% index_fetch_heap
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Michael PaquierДата:
Сообщение: Re: Better support of exported snapshots with pg_dump