Re: Wait free LW_SHARED acquisition - v0.9

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Wait free LW_SHARED acquisition - v0.9
Date: 2014-10-10 11:48:46
Message-ID: CAA4eK1LUNv6qzcCLh_vete6Cbm-CZ0wTifPzG2YQOMrLjiRx4g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 10, 2014 at 1:27 PM, Andres Freund <andres(at)2ndquadrant(dot)com>
wrote:
> On 2014-10-10 10:13:03 +0530, Amit Kapila wrote:
> > I have done few performance tests for above patches and results of
> > same is as below:
>
> Cool, thanks.
>
> > Performance Data
> > ------------------------------
> > IBM POWER-7 16 cores, 64 hardware threads
> > RAM = 64GB
> > max_connections =210
> > Database Locale =C
> > checkpoint_segments=256
> > checkpoint_timeout =35min
> > shared_buffers=8GB
> > Client Count = number of concurrent sessions and threads (ex. -c 8 -j 8)
> > Duration of each individual run = 5mins
> > Test type - read only pgbench with -M prepared
> > Other Related information about test
> > a. This is the data for median of 3 runs, the detailed data of
individual
> > run
> > is attached with mail.
> > b. I have applied both the patches to take performance data.
> >
> >
> > Observations
> > ----------------------
> > a. The patch performs really well (increase upto ~40%) incase all the
> > data fits in shared buffers (scale factor -100).
> > b. Incase data doesn't fit in shared buffers, but fits in RAM
> > (scale factor -3000), there is performance increase upto 16 client
count,
> > however after that it starts dipping (in above config unto ~4.4%).
>
> Hm. Interesting. I don't see that dip on x86.

Is it possible that implementation of some atomic operation is costlier
for particular architecture?

I have tried again for scale factor 3000 and could see the dip and this
time I have even tried with 175 client count and the dip is approximately
5% which is slightly more than 160 client count.

Patch_ver/Client_count 175 HEAD 248374 PATCH 235669
> > Now probably these shouldn't matter much in case backend needs to
> > wait for other Exclusive locker, but I am not sure what else could be
> > the reason for dip in case we need to have Exclusive LWLocks.
>
> Any chance to get a profile?

Here it goes..

HEAD - client_count=128
-----------------------------------------

+ 7.53% postgres postgres [.] GetSnapshotData
+ 3.41% postgres postgres [.] AllocSetAlloc
+ 2.61% postgres postgres [.] AllocSetFreeIndex
+ 2.49% postgres postgres [.] _bt_compare
+ 2.43% postgres [kernel.kallsyms] [k] .__copy_tofrom_user
+ 2.40% postgres postgres [.]
hash_search_with_hash_value
+ 1.83% postgres postgres [.] tas
+ 1.29% postgres postgres [.] pg_encoding_mbcliplen
+ 1.27% postgres postgres [.] MemoryContextCreate
+ 1.22% postgres postgres [.]
MemoryContextAllocZeroAligned
+ 1.17% postgres postgres [.] hash_seq_search
+ 0.97% postgres postgres [.] LWLockRelease
+ 0.96% postgres postgres [.]
MemoryContextAllocZero
+ 0.91% postgres postgres [.]
GetPrivateRefCountEntry
+ 0.82% postgres postgres [.] AllocSetFree
+ 0.79% postgres postgres [.] LWLockAcquireCommon
+ 0.78% postgres postgres [.] pfree

Detailed Data
-------------------------
- 7.53% postgres postgres [.] GetSnapshotData
- GetSnapshotData
- 7.46% GetSnapshotData
- 7.46% GetTransactionSnapshot
- 3.74% exec_bind_message
PostgresMain
BackendRun
BackendStartup
ServerLoop
PostmasterMain
main
generic_start_main.isra.0
__libc_start_main
0
- 3.72% PortalStart
exec_bind_message
PostgresMain
BackendRun
BackendStartup
ServerLoop
PostmasterMain
main
generic_start_main.isra.0
__libc_start_main
0
- 3.41% postgres postgres [.] AllocSetAlloc
- AllocSetAlloc
- 2.01% AllocSetAlloc
0.81% palloc
0.63% MemoryContextAlloc
- 2.61% postgres postgres [.] AllocSetFreeIndex
- AllocSetFreeIndex
1.59% AllocSetAlloc
0.79% AllocSetFree
- 2.49% postgres postgres [.] _bt_compare
- _bt_compare
- 1.80% _bt_binsrch
- 1.80% _bt_binsrch
- 1.21% _bt_search
_bt_first

Lwlock_contention patches - client_count=128
----------------------------------------------------------------------

+ 7.95% postgres postgres [.] GetSnapshotData
+ 3.58% postgres postgres [.] AllocSetAlloc
+ 2.51% postgres postgres [.] _bt_compare
+ 2.44% postgres postgres [.]
hash_search_with_hash_value
+ 2.33% postgres [kernel.kallsyms] [k] .__copy_tofrom_user
+ 2.24% postgres postgres [.] AllocSetFreeIndex
+ 1.75% postgres postgres [.]
pg_atomic_fetch_add_u32_impl
+ 1.60% postgres postgres [.] hash_seq_search
+ 1.31% postgres postgres [.] pg_encoding_mbcliplen
+ 1.27% postgres postgres [.]
MemoryContextAllocZeroAligned
+ 1.26% postgres postgres [.] MemoryContextCreate
+ 0.98% postgres postgres [.] GetPrivateRefCountEntry
+ 0.97% postgres postgres [.] MemoryContextAllocZero
+ 0.87% postgres postgres [.] LWLockRelease
+ 0.82% postgres postgres [.] AllocSetFree
+ 0.79% postgres postgres [.] SearchCatCache
+ 0.70% postgres postgres [.] palloc
0.69% postgres postgres [.] pfree
+ 0.61% postgres postgres [.] AllocSetDelete
+ 0.57% postgres postgres [.] hash_any
0.57% postgres postgres [.] MemoryContextAlloc
0.56% postgres postgres [.] FunctionCall2Coll
+ 0.56% swapper [kernel.kallsyms] [k]
.pseries_dedicated_idle_sleep
0.56% postgres libc-2.14.90.so [.] memcpy
+ 0.55% postgres postgres [.] AllocSetReset
0.51% postgres postgres [.] _bt_binsrch
0.50% postgres postgres [.] LWLockAcquireCommon

Detailed Data
----------------------------
- 7.95% postgres postgres [.] GetSnapshotData

- GetSnapshotData

- 7.87% GetSnapshotData

- 7.87% GetTransactionSnapshot

- 3.95% exec_bind_message

0

- 3.92% PortalStart

exec_bind_message

0

- 3.58% postgres postgres [.] AllocSetAlloc

- AllocSetAlloc

- 1.82% AllocSetAlloc

0.75% palloc

0.56% MemoryContextAlloc

- 2.51% postgres postgres [.] _bt_compare

- _bt_compare

- 1.75% _bt_binsrch

- 1.75% _bt_binsrch

- 1.18% _bt_search

_bt_first

btgettuple

- 2.44% postgres postgres [.]
hash_search_with_hash_value

- hash_search_with_hash_value

- 2.01% hash_search_with_hash_value

- 0.96% BufTableLookup

BufferAlloc

- 2.33% postgres [kernel.kallsyms] [k] .__copy_tofrom_user

- .__copy_tofrom_user

- 2.27% .file_read_actor

.generic_file_aio_read

.do_sync_read

- 2.24% postgres postgres [.] AllocSetFreeIndex

- AllocSetFreeIndex

1.23% AllocSetAlloc

0.68% AllocSetFree

- 1.75% postgres postgres [.]
pg_atomic_fetch_add_u32_impl

- pg_atomic_fetch_add_u32_impl

0.95% pg_atomic_fetch_add_u32

0.75% pg_atomic_fetch_sub_u32_impl

- 1.60% postgres postgres [.] hash_seq_search

- hash_seq_search

- 0.91% PreCommit_Portals

- 0.91% PreCommit_Portals

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2014-10-10 12:10:13 Re: Yet another abort-early plan disaster on 9.3
Previous Message Stephen Frost 2014-10-10 11:45:46 Re: Column Redaction