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 -
> ------------------------------------------------------------------------------------------
>
> 9.24% swapper [unknown] [H] 0x00000000011d9c10
> + 7.19% postgres postgres [.] s_lock
> + 3.52% postgres postgres [.] GetSnapshotData
> + 3.02% postgres postgres [.] calc_bucket
> + 2.71% postgres postgres [.]
> hash_search_with_hash_value
> 2.32% postgres [unknown] [H] 0x00000000011e0d7c
> + 2.17% postgres postgres [.]
> pg_atomic_fetch_add_u32_impl
> + 1.84% postgres postgres [.] AllocSetAlloc
> + 1.57% postgres postgres [.] _bt_compare
> + 1.05% postgres postgres [.] AllocSetFreeIndex
> + 1.02% postgres [kernel.kallsyms] [k]
> .__copy_tofrom_user_power7
> + 0.94% postgres postgres [.] tas
> + 0.85% swapper [kernel.kallsyms] [k] .int_sqrt
> + 0.80% postgres postgres [.] pg_encoding_mbcliplen
> + 0.78% pgbench [kernel.kallsyms] [k] .find_busiest_group
> 0.65% pgbench [unknown] [H] 0x00000000011d96e0
> + 0.59% postgres postgres [.] hash_any
> + 0.54% postgres postgres [.] LWLockRelease
This profile is without -O2 again. I really don't think it makes much
sense to draw much inference from an unoptimized build. I realize that
you said that the builds you use for benchmarking don't have that
problem, but that doesn't make this profile meaningful...
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services