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 1pxeRT-0004RB-9f for pgsql-admin@arkaria.postgresql.org; Sat, 13 May 2023 01:53:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pxeRS-00062i-7Y for pgsql-admin@arkaria.postgresql.org; Sat, 13 May 2023 01:53:02 +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 1pxeRR-00062P-TH for pgsql-admin@lists.postgresql.org; Sat, 13 May 2023 01:53:01 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pxeRN-0021tn-Kv for pgsql-admin@lists.postgresql.org; Sat, 13 May 2023 01:53:00 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 34D1qtCO1634074; Fri, 12 May 2023 21:52:55 -0400 From: Tom Lane To: Alex Balashov cc: pgsql-admin Subject: Re: Unexplained rapid growth in memory usage of idle backends In-reply-to: <2D17E15D-8D5B-4DF7-A238-12455C2731D8@evaristesys.com> References: <2D17E15D-8D5B-4DF7-A238-12455C2731D8@evaristesys.com> Comments: In-reply-to Alex Balashov message dated "Fri, 12 May 2023 18:12:10 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1634072.1683942775.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 12 May 2023 21:52:55 -0400 Message-ID: <1634073.1683942775@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Alex Balashov writes: > Occasionally, about once every 2 months, we'll get a slow-motion implosi= on over a period of about 24 hours, where the resident memory size of some= of the backends shoots up from a reasonable few hundred MB to several gig= s -- and will keep growing, e.g. I'm a little suspicious that the excess memory consumption is a consequence of JIT-compiled code not getting recycled promptly. Do you have JIT enabled, and if so are you relying on it too much to turn it off? I don't have any concrete idea of why JIT code management would work fine and then stop working fine, but we do have other reports of memory leaks from that. regards, tom lane