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 1noWwI-00075w-Qi for pgsql-admin@arkaria.postgresql.org; Tue, 10 May 2022 20:58:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1noWwH-0005jH-7u for pgsql-admin@arkaria.postgresql.org; Tue, 10 May 2022 20:58:37 +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 1noWwG-0005j8-RT for pgsql-admin@lists.postgresql.org; Tue, 10 May 2022 20:58:36 +0000 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1noWwA-0004cU-IU for pgsql-admin@lists.postgresql.org; Tue, 10 May 2022 20:58:36 +0000 Received: by mail-ej1-x634.google.com with SMTP id g6so279827ejw.1 for ; Tue, 10 May 2022 13:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tiOon8cO4pwzv0UeeGIuL8BYF4y7bdJ1XaEXkovirEI=; b=TX1pXwdDLTA36sH9ysjd/KyaFbPqFEpX3WE2M37T8/bLBagMPbQVywIbH5t/0eNYyq KCyMBEUvoJsZt2bfZrPd/4e11t5/R8a18yCnn/Lxv+Aubm5BZ/dJzYkTE9ri2ZrB0saI vl4Tgws7y2E54gmioM4IvZ1p0WSaCxw230XSvUNKlB6/6j7Z2jW6hqVZVyO7UTpYZ9VJ waKSNvyAeIxnWiH0Qm1geaDovzw5fe27zt3L417MachoOF8LI4wNtRt1h4YjhIX76gii OLFssN655wf/C9rKucUETZiaB0Vibuk9NVUI2Fa52ZGFRTk+5zXewD2/882k1nQzw5TT mxcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tiOon8cO4pwzv0UeeGIuL8BYF4y7bdJ1XaEXkovirEI=; b=FTWon8kNxaN655dGsrtMId12hCjRN9jy/h3nSrWF9YDxfXlBq8Js2NMZMVZ/8m/Z6W hzcT/ViiP03SeXuS3xTSVcNWx8BAoE+q/uqBLkE1QbURDgSmvjHChiMtxnVFvZhxFjsw bx0LY+kUAAvtyoukGE2S6JeIcFZto576G675XeYd68nDQZ4Auzr+NMtrCtcvaKNIyKtj SQpPNugveBo5EaAmqzWTd5wsmSkmt31URNnSsd2G9tXseogtVOIGHGAUsuysY3nsDNVa BQUJkubREXa9p0pQgi5peg7D22EtGpXSANxwcj5xDnKXxhiIhhG9AtdDXmkHBTVrcAu4 /dqg== X-Gm-Message-State: AOAM532Qcrqal1ntFQ6C+kwjhReU3kkJhxQVFKAV5oGN3p1SiTwDROrD 3qJsi4cEZ7Nv+NoVyYVbBeco3uhwZlKrQKd20xk= X-Google-Smtp-Source: ABdhPJznFdPeTxVdCOpXX6wMX/t+qv+i7DP/cXpX/6KzcWeaL9MUEVKXWToTb+veUs/5DNHwqTsowN80G3/qMjmjqxM= X-Received: by 2002:a17:906:7e50:b0:6f4:3767:b70c with SMTP id z16-20020a1709067e5000b006f43767b70cmr21207952ejr.433.1652216309719; Tue, 10 May 2022 13:58:29 -0700 (PDT) MIME-Version: 1.0 References: <3C248C6F-BB01-4E18-8427-EE46B9B48762@elevated-dev.com> <20220510204855.GE7402@aart.rice.edu> In-Reply-To: <20220510204855.GE7402@aart.rice.edu> From: Albin Ary Date: Tue, 10 May 2022 22:58:15 +0200 Message-ID: Subject: Re: Tuning Linux for Postgresql - Database failed to start To: Kenneth Marshall Cc: pgsql-admin@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000003ba5d505deae964e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003ba5d505deae964e Content-Type: text/plain; charset="UTF-8" Ok, will do that. Thanks a lot. It is clear now why it fails to start. Actually, the blog author mentions that setting it high might cause the database failing to start, anyway a calculation is provided and I followed that calculation. The ideal number of huge pages is just a bit higher than this -- just a > bit. If you increase this value too much, processes that need small pages > that also need space in the OS will fail to start. This may even end up > with the operating system failing to boot or other PostgreSQL instances on > the same server failing to start. On Tue, 10 May 2022 at 22:48, Kenneth Marshall wrote: > On Tue, May 10, 2022 at 10:39:09PM +0200, Albin Ary wrote: > > Hello, > > > > Thanks a lot for your inputs. > > > > I only changed the section related to HugePages. > > > > This server has 4 GB RAM. > > > > shared_buffers = '1GB' > > vm.nr_hugepages=650 > > > > tuned profile: > > > Hi Albin, > > 1GB shared_buffers + 1.3GB huge pages on a 4GB system = don't have > enough resources. Please remove the huge pages request or add additional > memory to your system. > > Regards, > Ken > --0000000000003ba5d505deae964e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok, will do that. Thanks a lot.=C2=A0

I= t is clear now why it fails to start.=C2=A0

Actual= ly, the blog author mentions that setting it high might cause the database = failing to start, anyway a calculation is provided and I=C2=A0followed that= calculation.=C2=A0


The= ideal number of huge pages is just a bit higher than this -- just a bit. I= f you increase this value too much, processes that need small pages that al= so need space in the OS will fail to start. This may even end up with the o= perating system failing to boot or other PostgreSQL instances on the same s= erver failing to start.



On Tue, 10 May 2022 at 22:48, Kenneth Marshall <ktm@rice.edu> wrote:
On Tue, May 10, 2022 at 10:39:09PM +0200, = Albin Ary wrote:
> Hello,
>
> Thanks a lot for your inputs.
>
> I only changed the section related to HugePages.
>
> This server has 4 GB RAM.
>
> shared_buffers =3D '1GB'
> vm.nr_hugepages=3D650
>
> tuned profile:
>
Hi Albin,

1GB shared_buffers + 1.3GB huge pages on a 4GB system =3D don't have enough resources. Please remove the huge pages request or add additional memory to your system.

Regards,
Ken
--0000000000003ba5d505deae964e--