On Tue, Oct 14, 2014 at 3:32 PM, Andres Freund <and...@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.

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



With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Reply via email to