Subject: Re: How to prioritise walsender reading from pg_wal over WAL writes?
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: pgsql-performance@postgresql.org
References: <774ec1b8-c7c6-cfa2-098d-5c6a32dcfc1a@imap.cc>
 <e40e61e6671d02ce79512439054bda9932bef8c1.camel@cybertec.at>
 <de2437b8-6de7-b9ce-0835-2d57e989ee30@imap.cc>
 <6a3a9ef99167a7baeaeee3d3df4af59694277e36.camel@cybertec.at>
From: Alexey Bashtanov <bashtanov@imap.cc>
Message-ID: <754ba288-1c2c-a4b4-0fb3-38fbc03053fd@imap.cc>
Date: Thu, 19 Nov 2020 13:38:46 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <6a3a9ef99167a7baeaeee3d3df4af59694277e36.camel@cybertec.at>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk


> I would first determine where the bottleneck is.
>
> Is it really the walsender, or is it on the network or in the standby server's replay?
It is really the walsender, and it really is the performance of the WAL 
storage on the master.
> Check the difference between "sent_lsn", "replay_lsn" from "pg_stat_replication" and
> pg_current_wal_lsn() on the primary.
Yes I've checked these numbers, the lagging one is sent_lsn.
It doesn't look like it's hitting network capacity either.
When we moved it to an NVMe as a short-term solution it worked fine.

Best, Alex