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 1oU18d-0004DD-40 for pgsql-hackers@arkaria.postgresql.org; Fri, 02 Sep 2022 07:30:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oU18b-0007Kq-FP for pgsql-hackers@arkaria.postgresql.org; Fri, 02 Sep 2022 07:30:49 +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 1oU18a-0007Kh-SO for pgsql-hackers@lists.postgresql.org; Fri, 02 Sep 2022 07:30:49 +0000 Received: from smtp-fw-9103.amazon.com ([207.171.188.200]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oU18X-000092-7v for pgsql-hackers@lists.postgresql.org; Fri, 02 Sep 2022 07:30:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1662103845; x=1693639845; h=message-id:date:mime-version:subject:to:references:from: in-reply-to:content-transfer-encoding; bh=qBJHXSqrFN54xnjOpAvMBG1k6IKgZddVieB4O2eqhaQ=; b=ccgKw9Wz+L/sQJdJepn4hH5aPZ35wGyS7eactDnuksgghjXxc62V866v lRaEaGyzcrCKpPVI1XEE9ZFtDwpeT2gsXLIntdizL+7sIlQGVxONsxUhk wBdvgWkeUKst/k0hYs1drB3Z/seVpMsJWxnXB/pz3ICvZxvYik+4Iwnoo s=; X-IronPort-AV: E=Sophos;i="5.93,283,1654560000"; d="scan'208";a="1050603186" Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO email-inbound-relay-iad-1d-10222bbc.us-east-1.amazon.com) ([10.25.36.214]) by smtp-border-fw-9103.sea19.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Sep 2022 07:30:29 +0000 Received: from EX13D03EUC003.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan3.iad.amazon.com [10.40.163.38]) by email-inbound-relay-iad-1d-10222bbc.us-east-1.amazon.com (Postfix) with ESMTPS id 397E01A002A; Fri, 2 Sep 2022 07:30:27 +0000 (UTC) Received: from [192.168.28.89] (10.43.160.191) by EX13D03EUC003.ant.amazon.com (10.43.164.192) with Microsoft SMTP Server (TLS) id 15.0.1497.38; Fri, 2 Sep 2022 07:30:26 +0000 Message-ID: <3b9b90c6-f4ae-a7df-6519-847ea9d5fe1e@amazon.com> Date: Fri, 2 Sep 2022 09:30:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: Add the ability to limit the amount of memory that can be allocated to backends. Content-Language: en-US To: , pgsql-hackers References: From: "Drouvot, Bertrand" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.43.160.191] X-ClientProxiedBy: EX13D02UWC001.ant.amazon.com (10.43.162.243) To EX13D03EUC003.ant.amazon.com (10.43.164.192) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 8/31/22 6:50 PM, Reid Thompson wrote: > Hi Hackers, > > Add the ability to limit the amount of memory that can be allocated to > backends. Thanks for the patch. + 1 on the idea. > Specifies a limit to the amount of memory (MB) that may be allocated to > backends in total (i.e. this is not a per user or per backend limit). > If unset, or set to 0 it is disabled. It is intended as a resource to > help avoid the OOM killer. A backend request that would push the total > over the limit will be denied with an out of memory error causing that > backends current query/transaction to fail. I'm not sure we are choosing the right victims here (aka the ones that are doing the request that will push the total over the limit). Imagine an extreme case where a single backend consumes say 99% of the limit, shouldn't it be the one to be "punished"? (and somehow forced to give the memory back). The problem that i see with the current approach is that a "bad" backend could impact all the others and continue to do so. what about punishing say the highest consumer , what do you think? (just speaking about the general idea here, not about the implementation) Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com