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 1lr3oB-0006qg-14 for pgsql-admin@arkaria.postgresql.org; Wed, 09 Jun 2021 19:24:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lr3o9-0002Bj-Qe for pgsql-admin@arkaria.postgresql.org; Wed, 09 Jun 2021 19:24:09 +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 1lr3o9-0002BP-Hx for pgsql-admin@lists.postgresql.org; Wed, 09 Jun 2021 19:24:09 +0000 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lr3o4-0006X9-Ib for pgsql-admin@postgresql.org; Wed, 09 Jun 2021 19:24:08 +0000 Received: by mail-ej1-x634.google.com with SMTP id k25so34603782eja.9 for ; Wed, 09 Jun 2021 12:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=x0TxYD3NAswvsZ+y2rqlpllPUABo5iu5mWURJJoCYoY=; b=N4zs8Mvp9SmgTgSft30U68fREGlM4QLQYLXXMbwF9LrYK4uCuo9YkBggcPxk4YJ9vS YK0IbVMD5D30R5YdOVg+NA9qwL7X4M34zLc0awkkIkCWNl6Htifbby8SB6VqZNohXr6W hHG8m+xjSLqQ28n/QJ1+0MEmh8imF/mXAAEClumXLQ+sZGk6PFgQvpWZb4lCI0DsCgqe r356pWcnPYSeWEkj2k84g1snPAgc2mKYtj95ppcaXe8sIXnvq8Z0Hs02wF6ma9JLgzgB uKdo/olCdSlEnOwa18vgq/Z4Q2NCdYfGSJnHJ/uom5FaaRUHgW6MV83Pi7dD6lFntqLZ 2SKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=x0TxYD3NAswvsZ+y2rqlpllPUABo5iu5mWURJJoCYoY=; b=czVhPdsBbibFYAfSIEQQ3Fc7RmKsyaVMA+NKiaFlrMZp7PVTkyqbTKGZ379DmlKOCN 9LtFuFAYo53YlPKxcm+IcFpjCbN8F6atJ19lzoXe7ieVShSIXR7MkAvL/uWEQLRI8cPu 4rxENKgv2hvaCRothcajEFQU2vbFpfIi8W3xBFKZ7gaTXsEWJLJ3t9yn+XQO3FlQxdVK 2E9mYoGx4U2JFQlAfqN7MyFST0oHwNktpA4IjHhk3jWUea2ZnzXsfH7SlUIzKZWkq1RF Zf+bnY1g3w8U8sJcyh6LdOkivE2TQEcK6w+NsaHd2G4Rut0f1oJUHQeqMyWPuDbnaRlV fVYg== X-Gm-Message-State: AOAM5303MKPiPhYuEUJHeFJDMNY0SHah7DsOBjDu+pkcH9JotJ8B6Fgm b0eNz6yJl6xRofE10gnxTp1vCo28YrDPgMZUeEwb3bwslP0= X-Google-Smtp-Source: ABdhPJxcaydCk9vYX2iRUGtID3Jwesxrcyj5OKhNHJyEFXjNt1EGfkhsXebG4xPDG2AXPf/LScq0gOSDdf8mNUvFTI4= X-Received: by 2002:a17:906:9143:: with SMTP id y3mr1218186ejw.465.1623266642687; Wed, 09 Jun 2021 12:24:02 -0700 (PDT) MIME-Version: 1.0 References: <1428485.1623266137@sss.pgh.pa.us> In-Reply-To: <1428485.1623266137@sss.pgh.pa.us> From: Magnus Hagander Date: Wed, 9 Jun 2021 21:23:50 +0200 Message-ID: Subject: Re: Estimating HugePages Requirements? To: Tom Lane Cc: Julien Rouhaud , Don Seiler , pgsql-admin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jun 9, 2021 at 9:15 PM Tom Lane wrote: > > Magnus Hagander writes: > > I wonder how hard it would be to for example expose that through a > > commandline switch or tool. > > Just try to start the server and see if it complains. > For instance, with shared_buffers=3D10000000 I get > > 2021-06-09 15:08:56.821 EDT [1428121] FATAL: could not map anonymous sha= red memory: Cannot allocate memory > 2021-06-09 15:08:56.821 EDT [1428121] HINT: This error usually means tha= t PostgreSQL's request for a shared memory segment exceeded available memor= y, swap space, or huge pages. To reduce the request size (currently 8372056= 8832 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing s= hared_buffers or max_connections. > > Of course, if it *does* start, you can do the other thing. Well, I have to *stop* the existing one first, most likely, otherwise there won't be enough huge pages (or indeed memory) available. And if then doesn't start, you're looking at extended downtime. You can automate this to minimize it (set the value in the conf, stop old, start new, if new doesn't start then stop new, reconfigure, start old again), but it's *far* from friendly. This process works when you're setting up a brand new server with nobody using it. It doesn't work well, or at all, when you actually have active users on it.. > Admittedly, we could make that easier somehow; but if it took > 25 years for somebody to ask for this, I'm not sure it's > worth creating a feature to make it a shade easier. We haven't had huge page support for 25 years, "only" since 9.4 so about 7 years. And for every year that passes, huge pages become more interesting in that in general memory sizes increase so the payoff of using them is increased. Using huge pages *should* be a trivial improvement to set up. But it's in my experience complicated enough that many just skip it simply for that reason. --=20 Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/