Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDWcH-001JAp-Ue for pgsql-general@arkaria.postgresql.org; Tue, 19 Nov 2024 22:22:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tDWcE-0003WL-TO for pgsql-general@arkaria.postgresql.org; Tue, 19 Nov 2024 22:22:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDWcE-0003WD-Fk for pgsql-general@lists.postgresql.org; Tue, 19 Nov 2024 22:22:34 +0000 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tDWcB-002ox3-TU for pgsql-general@lists.postgresql.org; Tue, 19 Nov 2024 22:22:33 +0000 Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a9ed7d8c86cso965332966b.2 for ; Tue, 19 Nov 2024 14:22:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732054950; x=1732659750; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=IXBs8A1nbuQu1WhOzOVBfFGXqEdhM9qi50yjKxPA4eg=; b=cltNCyarvIEmr5nz8S+viUXtk9pWNncEh9PIrU6PRIfA1r11W/h481W0TSB45G/Tt1 hGfZO+zlUD6oG9C5PUEnjgDoeVOs9/yeSuOK3nySXKq3vCZwKfSvgy8spMeDllx+UhQU 0Io54YpKWfKmrFwgRMgkkYB9jJcfn89vP9f/QDbn0AYieZRXy/ABbvmROzGFuTvdbt+1 ktclB9g/JCEjBjFrDGyToESSA2AaeOb92xXm+PqTN2OlXoC+T75YtG5DucgZ3Cm9XuA+ IRxZLlTNy/NHTVXZZHAzhELXnLhF1+mA3ZeTvl/C2ALPFAeMKZx+vkFCW+H0EXsfF/G0 J7fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732054950; x=1732659750; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=IXBs8A1nbuQu1WhOzOVBfFGXqEdhM9qi50yjKxPA4eg=; b=Fp3DOkOer9qoX41WUwLCystvqm3tYeBjUPEnsmSELb9u3xUZ5yauDJk9eujmOMwCk5 V4CmeKWa4YeH9drB/bG+S2+IRln/KfGE8Mr0hhgxh7QBbtXxVMBesPbatiFqV30IVHUx fmycy6TaO9qYBp/A9OsmxfcMIXHdwjH2RJ5IRfojUcRgwiA6hXnFt+4jSqVE9ubCmSm6 saQ6WdVVU0vIzngtQV5utZ150SNY6CEThnzLWauqsRu1axQz9BaRGq0qxFLMtInzeNoi YGNZt+O1KsSlfDIR3lb9g35uZ4x7n5b9AUMvDTNP7j3vXom8ceFt0iBimSGUy0mVM0UR Xogg== X-Gm-Message-State: AOJu0Yx46LQXJY0VaP0bEjMP+VaPHdXzu2bX3mO5ysMKUunmL75Aj4S+ s7xsDHGMIZ2vdZ2/7xLt0yY8tD9oi6dqVsxks+B4Kz+j4N1IK+b6uRQXjPgazh4JJkETM/ibc92 NS5cJiHgVGsnDbUFs+4WCkEGoFt9Uj7uh X-Google-Smtp-Source: AGHT+IEL+nqaAXJLay0YM1gp3EnnYloOJDY1YjTMl8UkgBhEInkmEczZsH9VJJ6ZSBIS2FDgf+2JSnuGT3hZqdJh3es= X-Received: by 2002:a17:907:d90:b0:aa4:a3be:28dd with SMTP id a640c23a62f3a-aa4dd753937mr44087066b.55.1732054950467; Tue, 19 Nov 2024 14:22:30 -0800 (PST) MIME-Version: 1.0 From: Koen De Groote Date: Tue, 19 Nov 2024 23:22:18 +0100 Message-ID: Subject: Running docker in postgres, SHM size of the docker container in postgres 16 To: PostgreSQL General Content-Type: multipart/alternative; boundary="0000000000000ddd4406274b7895" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000000ddd4406274b7895 Content-Type: text/plain; charset="UTF-8" Hello all, Assume a machine with 16 CPU cores and 64GB of RAM. 300 max connections. Postgres is running here, inside a docker container. Docker containers receive a small amount of shared memory from /dev/shm Experience teaches that the default 64MB of /dev/shm for the postgres container, is not enough for databases of even 50GB in size. Previously I've increased the /dev/shm setting to 256MB for the postgres container. Issues that made this necessary all came in the form of too many queries running at once, asking too much memory space, I assume. I recently upgraded a setup from postgres 11 to postgres 16 via logical replication, and found that running "vacuum(analyze, verbose)" fails unless I give the container 1GB of /dev/shm. Where previously 256MB sufficed on the old postgres 11 version. Why would that be? It's the exact same data. The install is about 50GB in size. Is there something wrong with postgres 16, or did some settings significantly change, that I need to know about? I went over all the changelogs, nothing stood out as relevant to this, but that might be a lack of experience on my end. Regards, Koen De Groote --0000000000000ddd4406274b7895 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

Assume a machine = with 16 CPU cores and 64GB of RAM. 300 max connections.

<= /div>Postgres is running here, inside a docker container. Docker containers= receive a small amount of shared memory from /dev/shm

Experience teaches that the default 64MB of /dev/shm for the postgr= es container, is not enough for databases of even 50GB in size. Previously = I've increased the /dev/shm setting to 256MB for the postgres container= . Issues that made this necessary all came in the form of too many queries = running at once, asking too much memory space, I assume.

=
I recently upgraded a setup from postgres 11 to postgres 16 via = logical replication, and found that running "vacuum(analyze, verbose)&= quot; fails unless I give the container 1GB of /dev/shm. Where previously 2= 56MB sufficed on the old postgres 11 version.

= Why would that be? It's the exact same data. The install is about 50GB = in size. Is there something wrong with postgres 16, or did some settings si= gnificantly change, that I need to know about? I went over all the changelo= gs, nothing stood out as relevant to this, but that might be a lack of expe= rience on my end.

Regards,
Koen De G= roote
--0000000000000ddd4406274b7895--