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 1mDIbP-0005eQ-Qh for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Aug 2021 03:38:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mDIbO-00072j-OD for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Aug 2021 03:38:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mDIbO-00072b-Fy for pgsql-hackers@lists.postgresql.org; Tue, 10 Aug 2021 03:38:54 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mDIbJ-0006q5-Jp for pgsql-hackers@postgresql.org; Tue, 10 Aug 2021 03:38:54 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id D37E93200931; Mon, 9 Aug 2021 23:38:46 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 09 Aug 2021 23:38:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=QIQk/ddrRkLjfAvjKPJEvREu4SN GlFjJDyjIw1xbzow=; b=X1M+ys1JJEVtXXZyA+L8lQGQXstb6jBXix2Wam/CJoS FF6TCakMSgHPXnxk89EDtJwePLMEMmjjKrgjKNQvcXg9jbt4cvGfqQisuuY14F5c 6+INEpe71DXIPNW/zZm9ejDMLgCISaBvFBHHzkN52mzzC8DLJ0H58X9ZuO+1zXE7 snfjDQ4TtilLb59b7Z5Hu/78nPtO+Pe03K4Oq+GLqXAC3fygI2VaV+GSVcznKu77 NvrDzR69snKuzHdKlHftg6PObyLwLik4uqkoQsYaU0PxwjMh0OZ5bQN/dM5A/z7I Y5S+lPez50mm+4ceaWj9tLY7ALW8Bnk+NjqW8M//LIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=QIQk/d drRkLjfAvjKPJEvREu4SNGlFjJDyjIw1xbzow=; b=jWR+jWYdofi4KbJlTXWZEx ll6gUN4h9W2sJ+5T3fHC4QfosxDTAiid9JZ6CxkfdCebi4JPsFon4v7pB3dVzH7q bqHdRqCwcdGab1f6CK48xCFw7ZivXniDjmCZ/7TteArbMiLwDDNAGZmbCJGKyRNK dKSNUixF36idlibPua0JPOr1zK5WVn8CU8GOaDeY6Yyu/J4S1ERqeK6AGzprru5X juioSPLrqjmfhXgmFzKjEozXVY4KtUQ/i/An5zSPTqg2kbGZM6CwOLR/kmE93uIb qG2N91POWfF42qizyzwS+MDpmfJOt2TQ7WAS1ieqoonhCSnP8SFZYX6IDnIqsQcw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrjeekgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomheptehnughrvghs ucfhrhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecuggftrfgrth htvghrnhepudekhfekleeugeevteehleffffejgeelueduleeffeeutdelffeujeffhfeu ffdunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hnughrvghssegrnhgrrhgriigvlhdruggv X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 9 Aug 2021 23:38:43 -0400 (EDT) Date: Mon, 9 Aug 2021 20:38:32 -0700 From: Andres Freund To: Justin Pryzby Cc: Don Seiler , P C , Magnus Hagander , Julien Rouhaud , Tom Lane , pgsql-hackers@postgresql.org Subject: Re: Estimating HugePages Requirements? Message-ID: <20210810033832.ueaicvx34ehh7q2p@alap3.anarazel.de> References: <1428485.1623266137@sss.pgh.pa.us> <1429225.1623266925@sss.pgh.pa.us> <20210611002333.GK16435@telsasoft.com> <20210809235852.GA2426@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210809235852.GA2426@telsasoft.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2021-08-09 18:58:53 -0500, Justin Pryzby wrote: > Define shared_buffers as the exact size to be allocated/requested from the OS > (regardless of whether they're huge pages or not), and have postgres compute > everything else based on that. So shared_buffers=2GB would end up being 1950MB > (or so) of buffer cache. We'd have to check that after the other allocations, > there's still at least 128kB left for the buffer cache. Maybe we'd have to > bump the minimum value of shared_buffers. I don't like that. How much "other" shared memory we're going to need is very hard to predict and depends on extensions, configuration options like max_locks_per_transaction, max_connections to a significant degree. This way the user ends up needing to guess at least as much as before to get to a sensible shared_buffers. Greetings, Andres Freund