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" <robertmhaas@gmail.com>
> Sent Time: 2017-06-08 01:30:58 (Thursday)
> To: "Mengxing Liu" <liu-mx15@mails.tsinghua.edu.cn>
> Cc: kgrittn <kgrittn@gmail.com>, "Alvaro Herrera" <alvherre@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-mx15@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