Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pWm5Q-0003PM-08 for pgsql-bugs@arkaria.postgresql.org; Mon, 27 Feb 2023 22:35:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pWm5O-0003tc-GF for pgsql-bugs@arkaria.postgresql.org; Mon, 27 Feb 2023 22:35:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pWm5O-0003tT-25 for pgsql-bugs@lists.postgresql.org; Mon, 27 Feb 2023 22:35:10 +0000 Received: from 17.mo561.mail-out.ovh.net ([87.98.178.58]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pWm5K-0001Dh-OF for pgsql-bugs@lists.postgresql.org; Mon, 27 Feb 2023 22:35:08 +0000 Received: from director1.ghost.mail-out.ovh.net (unknown [10.108.20.85]) by mo561.mail-out.ovh.net (Postfix) with ESMTP id 51A7623DAB for ; Mon, 27 Feb 2023 22:35:02 +0000 (UTC) Received: from ghost-submission-6684bf9d7b-nmk8r (unknown [10.110.208.235]) by director1.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 310441FD2F; Mon, 27 Feb 2023 22:35:01 +0000 (UTC) Received: from darold.net ([37.59.142.102]) by ghost-submission-6684bf9d7b-nmk8r with ESMTPSA id wxPOARUw/WMU/AEAObDfAA (envelope-from ); Mon, 27 Feb 2023 22:35:01 +0000 Authentication-Results: garm.ovh; auth=pass (GARM-102R004f6dbb660-b7fb-4bd1-ba66-717e7e151bb2, 07E3B4038E126A80A27BD94F9C2317F221191587) smtp.auth=gilles@darold.net X-OVh-ClientIp: 196.168.215.128 Content-Type: multipart/alternative; boundary="------------POGO54IrrAePrDbhyu5N5teB" Message-ID: <83b1108f-9552-3ebb-35fc-e00ac9ff0cf1@darold.net> Date: Mon, 27 Feb 2023 22:34:59 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 To: Alex Richman , Amit Kapila Cc: "wangw.fnst@fujitsu.com" , "pgsql-bugs@lists.postgresql.org" , Niels Stevens References: Content-Language: fr From: Gilles Darold Subject: Re: Logical Replica ReorderBuffer Size Accounting Issues In-Reply-To: X-Ovh-Tracer-Id: 3464956966030777950 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrudeludcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtkfffgggfvfevfhfhufgjsegrtderredtfeejnecuhfhrohhmpefiihhllhgvshcuffgrrhholhguuceoghhilhhlvghssegurghrohhlugdrnhgvtheqnecuggftrfgrthhtvghrnhepjeejudeltdffgeeuveekffduleeggfeggfdtgeffieduueeltdduteehhfevheffnecuffhomhgrihhnpehpohhsthhgrhgvshhqlhdrohhrghdpghhithhhuhgsrdgtohhmnecukfhppeduvdejrddtrddtrddupdefjedrheelrddugedvrddutddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpeeoghhilhhlvghssegurghrohhlugdrnhgvtheqpdhnsggprhgtphhtthhopedupdhrtghpthhtohepphhgshhqlhdqsghughhssehlihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrghdpoffvtefjohhsthepmhhoheeiuddpmhhouggvpehsmhhtphhouhht List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------POGO54IrrAePrDbhyu5N5teB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 16/02/2023 à 19:08, Alex Richman a écrit : > Hi all, > > Looping back to say we updated to 15.2 and are still seeing this > issue, though it is less prevalent. > > Thanks, > - Alex. > > On Wed, 18 Jan 2023 at 11:16, Alex Richman > wrote: > > > > On Wed, 18 Jan 2023 at 10:10, Amit Kapila > wrote: > > Alex, > Do we see this problem with small tuples as well? I see from your > earlier email that tuple size is ~800 bytes in the production > environment. It is possible that after commit 1b0d9aa4 such > kind of > problems are not there with small tuple sizes but that commit > happened > in PG15 whereas your production environment might be on a prior > release. > > > Hi Amit, > > Our prod environment is also on 15.1, which is where we first saw > the issue, so I'm afraid the issue still seems to be present here. > > Looping back on the earlier discussion, we applied the malloc > patch from [1] ([2]) to a prod server, which also fixes the issue > there.  Attached is a graph of the last 48 hours of memory usage, > the ~200GB spikes are instances of the LR walsender memory issue. > After patch is applied (blue mark), baseline memory drops and we > no longer see the spikes.  Per-process memory stats corroborate > that the LR walsender memory is now never more than a few MB RSS > per process. > > Thanks, > - Alex. > > [1] > https://www.postgresql.org/message-id/CAMnUB3pwknqoe5s-bGuRD8nX1bWkZRbFF%3DjWNLTWbm_etFigkA%40mail.gmail.com > [2] > https://gist.github.com/alex-richman-onesignal/4ad147b37eaab99f41a150b51899a564 > Hi, Amit / Wang Wei do you have a better patch to fix this bug or should we use the one provided by Alex? I have tried some other fixes but it's a fail, you may have better understanding of the problem and the way to fix it. Best regards -- Gilles Darold --------------POGO54IrrAePrDbhyu5N5teB Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Le 16/02/2023 à 19:08, Alex Richman a écrit :
Hi all,

Looping back to say we updated to 15.2 and are still seeing this issue, though it is less prevalent.

Thanks,
- Alex.

On Wed, 18 Jan 2023 at 11:16, Alex Richman <alexrichman@onesignal.com> wrote:


On Wed, 18 Jan 2023 at 10:10, Amit Kapila <amit.kapila16@gmail.com> wrote:
Alex,
Do we see this problem with small tuples as well? I see from your
earlier email that tuple size is ~800 bytes in the production
environment. It is possible that after commit 1b0d9aa4 such kind of
problems are not there with small tuple sizes but that commit happened
in PG15 whereas your production environment might be on a prior
release.

Hi Amit,

Our prod environment is also on 15.1, which is where we first saw the issue, so I'm afraid the issue still seems to be present here.

Looping back on the earlier discussion, we applied the malloc patch from [1] ([2]) to a prod server, which also fixes the issue there.  Attached is a graph of the last 48 hours of memory usage, the ~200GB spikes are instances of the LR walsender memory issue.
After patch is applied (blue mark), baseline memory drops and we no longer see the spikes.  Per-process memory stats corroborate that the LR walsender memory is now never more than a few MB RSS per process.

Thanks,
- Alex.


Hi,


Amit / Wang Wei do you have a better patch to fix this bug or should we use the one provided by Alex? I have tried some other fixes but it's a fail, you may have better understanding of the problem and the way to fix it.


Best regards

-- 
Gilles Darold
--------------POGO54IrrAePrDbhyu5N5teB--