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" <robertmh...@gmail.com> > Sent Time: 2017-06-08 01:30:58 (Thursday) > To: "Mengxing Liu" <liu-m...@mails.tsinghua.edu.cn> > Cc: kgrittn <kgri...@gmail.com>, "Alvaro Herrera" <alvhe...@2ndquadrant.com>, > "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org> > 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 > <liu-m...@mails.tsinghua.edu.cn> 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 (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Mengxing Liu -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
