Re: How to avoid the XLog Write to be the performance bottleneck

From: Andres Freund <andres(at)anarazel(dot)de>
To: 范国腾 <fanguoteng(at)highgo(dot)com>
Cc: "pgsql-admin(at)lists(dot)postgresql(dot)org" <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: How to avoid the XLog Write to be the performance bottleneck
Date: 2018-09-21 16:26:24
Message-ID: 20180921162624.jb63srqwnyfnx4bt@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

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 very high.
>
> In active node, we find that the disk IO is very high but the CPU of each postgres process is about 20%. The pstack result shows that most of the postgres process is waiting for the XLOG Write Lock. It seems that the XLog write become the bottleneck 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

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Prince Pathria 2018-09-21 21:11:56 WAL segments held for replcation
Previous Message Craig James 2018-09-21 15:21:45 Reversing pg_logical replication