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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers