On 2018-09-21 08:16:42 +0000, 范国腾 wrote:
> Hi,
>
> We have two postgres nodes（active/standby). The active node and the standby node use the same share disk（GFS2 file
system）.
>
> We are doing the performance test in active side:
> (1)Now there is no SQL request sending to the standby side.
> (2)The active node has 20 sessions and the test tool sends INSERT/UPDATE/SELECT request to them. The call load is
veryhigh.
>
> In active node, we find that the disk IO is very high but the CPU of each postgres process is about 20%. The pstack
resultshows that most of the postgres process is waiting for the XLOG Write Lock. It seems that the XLog write become
thebottleneck of the postgres database.
Usually that doesn't really mean there's lock contention, but that
your IO isn't fast enough. What you can do:
a) check whether some/most/all of your transactions can use
synchronous_commit = off - that can drastically reduce the amount of
IO.
b) Consider putting your WAL onto a separate disk (or even partition),
that can reduce overhead by disentangling synchronous writes (for the
WAL) from asynchronous writes (the data being written back), and
synchronous reads (queries).
c) Get faster storage.
Greetings,
Andres Freund