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 1mNUX5-00046L-1c for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Sep 2021 06:24:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mNUX3-0004im-RM for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Sep 2021 06:24:33 +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 1mNUX3-0004gu-Ga for pgsql-hackers@lists.postgresql.org; Tue, 07 Sep 2021 06:24:33 +0000 Received: from mail-pl1-x62b.google.com ([2607:f8b0:4864:20::62b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mNUWw-0001BH-Sx for pgsql-hackers@postgresql.org; Tue, 07 Sep 2021 06:24:32 +0000 Received: by mail-pl1-x62b.google.com with SMTP id n4so5168448plh.9 for ; Mon, 06 Sep 2021 23:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=gwiKpby7D9pUmSY9RooXS+swsR7zUgRgXc/jTie2B6k=; b=qLEWEBNEb4wkm5evaqFwG5tgnveI9An8PHM8OJ+rHBviURk/dz5146QccUlMKNvw+7 kxi/Z8lW7IuQYXbmDL+7AjfbQHeNSpC0RsVJS9MoCqmIuyxCe9tjtbCiGVzcqTTrBUXb tFshdiZJlvLLXYSF8BXEYWlRVcIka8YSai6TLR0nttkD2fSKfsCMVPS7CcLdKaJR032X IvpnYOcaPylKzQvinvjfJlYouQVVxIHFaY6Z9+qojo7/tNnQpS/VzDuL0UKJESV9wDB4 1oko09OijY+07DgGEHcRw3yDAh123aM/8mxQZkAHiJvom8129bAsKWTgcmj7I3k/RUD/ VK8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=gwiKpby7D9pUmSY9RooXS+swsR7zUgRgXc/jTie2B6k=; b=pYlrlH6BTrhG2GqqP/56tNcDf3PjmVrd7IZwHm0zIViosObDBURMUwf3IvlHg8rMEp sfPokpXuXzjGLcK15NFHxFjhzk1+k7RCx22CJJaBGWaBnv8RYXiXQBi008Ya8CDUrszD T9PYIJqOrgSpyvydEiApmj13HBC9ieqep27aMTVQeGWEDvrpTzKscB2OrfN4KLLR/sYv spoxmRCrGY+DriBMLXtXAYT7pEKKZKMKoI7StYquB26vMyThTNoGhiM8mtifTDJPch1t rW9knjMrHkoHatM9/IaCEhZO3F3nuNjSpfyLFx8Q4FksocAe7sYyt2qKmTYU1Fk5HkBQ WMgg== X-Gm-Message-State: AOAM532B233lGqiwN1lqFZyUwXEh0yDgCwHYy0IkJKLn0B4hIyzNWfAc JIbjGAtS35GbBsSeK4EJoNk= X-Google-Smtp-Source: ABdhPJwdfrclAOETFaxc6553jv9TEf+o+1jPFLmp++tZNZzlvnTspA0gRw4VR5zyxCYD2AcJQRodtw== X-Received: by 2002:a17:90a:e511:: with SMTP id t17mr2854036pjy.172.1630995865408; Mon, 06 Sep 2021 23:24:25 -0700 (PDT) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id h4sm11871785pgn.6.2021.09.06.23.24.22 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 06 Sep 2021 23:24:24 -0700 (PDT) Date: Tue, 07 Sep 2021 15:24:21 +0900 (JST) Message-Id: <20210907.152421.965153283301063555.horikyota.ntt@gmail.com> To: bossartn@amazon.com Cc: michael@paquier.xyz, pryzby@telsasoft.com, andres@anarazel.de, magnus@hagander.net, mark.dilger@enterprisedb.com, don@seiler.us, pgsql-hackers@postgresql.org Subject: Re: Estimating HugePages Requirements? From: Kyotaro Horiguchi In-Reply-To: References: <23F67FC0-E432-4324-BEA4-F99B126510EA@amazon.com> <20210903.141206.103927759882272221.horikyota.ntt@gmail.com> User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk At Fri, 3 Sep 2021 17:46:05 +0000, "Bossart, Nathan" wrote in > On 9/2/21, 10:12 PM, "Kyotaro Horiguchi" wrote: > > By the way I noticed that postgres -C huge_page_size shows 0, which I > > think should have the number used for the calculation if we show > > huge_page_required. > > I would agree with this if huge_page_size was a runtime-computed GUC, > but since it's intended for users to explicitly request the huge page > size, it might be slightly confusing. Perhaps another option would be > to create a new GUC for this. Or maybe it's enough to note that the > value will be changed from 0 at runtime if huge pages are supported. > In any case, it might be best to handle this separately. (Sorry, I was confused, but) yeah, agreed. > > I noticed that postgres -C shared_memory_size showed 137 (= 144703488) > > whereas the error message above showed 148897792 bytes (142MB). So it > > seems that something is forgotten while calculating > > shared_memory_size. As the consequence, launching postgres setting > > huge_pages_required (69 pages) as vm.nr_hugepages ended up in the > > "could not map anonymous shared memory" error. > > Hm. I'm not seeing this with the v5 patch set, so maybe I > inadvertently fixed it already. Can you check this again with v5? Thanks! I confirmed that the numbers match with v5. regards. -- Kyotaro Horiguchi NTT Open Source Software Center