Thank you very much! I follow your advice and here is the result. SerializableXactHashLock 73 predicate_lock_manager 605 WALWriteLock 3 SerializableFinishedListLock 665
There are more than 90 events each time. SerializableXactHashLock/SerializableFinishedListLock are both used in SSI. I think that's why PG is so slow in high contention environment. > -----Original Messages----- > From: "Robert Haas" <[email protected]> > Sent Time: 2017-06-08 01:30:58 (Thursday) > To: "Mengxing Liu" <[email protected]> > Cc: kgrittn <[email protected]>, "Alvaro Herrera" <[email protected]>, > "[email protected]" <[email protected]> > Subject: Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from > rw-conflict tracking in serializable transactions > > On Tue, Jun 6, 2017 at 12:16 PM, Mengxing Liu > <[email protected]> wrote: > > I think disk I/O is not the bottleneck in our experiment, but the global > > lock is. > > A handy way to figure this kind of thing out is to run a query like > this repeatedly during the benchmark: > > SELECT wait_event_type, wait_event FROM pg_stat_activity; > > I often do this by using psql's \watch command, often \watch 0.5 to > run it every half-second. I save all the results collected during the > benchmark using 'script' and then analyze them to see which wait > events are most frequent. If your theory is right, you ought to see > that SerializableXactHashLock occurs as a wait event very frequently. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > -- > Sent via pgsql-hackers mailing list ([email protected]) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Mengxing Liu -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
