Hi, 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. > > Scale Factor - 100 > > Patch_ver/Client_count 1 8 16 32 64 128 HEAD 13344 106921 196629 295123 > 377846 333928 PATCH 13662 106179 203960 298955 452638 465671 > > Scale Factor - 3000 > > Patch_ver/Client_count 8 16 32 64 128 160 HEAD 86920 152417 231668 > 280827 257093 255122 PATCH 87552 160313 230677 276186 248609 244372 > > > 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. > The above data shows that the patch improves performance for cases > when there is shared LWLock contention, however there is a slight > performance dip in case of Exclusive LWLocks (at scale factor 3000, > it needs exclusive LWLocks for buf mapping tables). Now I am not > sure if this is the worst case dip or under similar configurations the > performance dip can be higher, because the trend shows that dip is > increasing with more client counts. > > Brief Analysis of code w.r.t performance dip > --------------------------------------------------------------------- > Extra Instructions w.r.t Head in Acquire Exclusive lock path > a. Attempt lock twice > b. atomic operations for nwaiters in LWLockQueueSelf() and > LWLockAcquireCommon() > c. Now we need to take spinlock twice, once for self queuing and then > again for setting releaseOK. > d. few function calls and some extra checks Hm. I can't really see the number of atomics itself matter - a spinning lock will do many more atomic ops than this. But I wonder whether we could get rid of the releaseOK lock. Should be quite possible. > 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? 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
