MIME-Version: 1.0
References: <CAODqTUaYHVKWFitXQvdhn0jrmVL60=bTp=eOAX2dR7x0ymZshQ@mail.gmail.com>
 <61bb2e7f-9c29-4c3f-a316-60780ce5512a@vondra.me>
In-Reply-To: <61bb2e7f-9c29-4c3f-a316-60780ce5512a@vondra.me>
From: =?UTF-8?B?QWxlxaEgWmVsZW7DvQ==?= <zeleny.ales@gmail.com>
Date: Mon, 23 Jun 2025 11:32:40 +0200
Message-ID: <CAODqTUYKBEmSPxt8kD_6-oFFjz1sxiMBtJfZZqAFpzAxVGCpOw@mail.gmail.com>
Subject: Re: PostgreSQL 17.5 - could not map dynamic shared memory segment
To: "pgsql-generallists.postgresql.org" <pgsql-general@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000538cb3063839e537"
Archived-At: <https://www.postgresql.org/message-id/CAODqTUYKBEmSPxt8kD_6-oFFjz1sxiMBtJfZZqAFpzAxVGCpOw%40mail.gmail.com>
Precedence: bulk

--000000000000538cb3063839e537
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,
Thanks for the good point:

$ sysctl vm.overcommit_memory
vm.overcommit_memory =3D 0

That is a difference, the old pg11 running on Ubuntu 18.4 had
disabled overcommit  (vm.overcommit_memory =3D 2).

Anyway, on a dedicated DB server box with 123GB RAM running only vacuum (14
parallel processes (2GB maintenance workmen)) and shared buffers 22GB seems
to me unlikely to hit available memory.

During Sunday (low load) and Monday so far, it has not reoccurred.

Kind regards Ales Zeleny

ne 22. 6. 2025 v 0:44 odes=C3=ADlatel Tomas Vondra <tomas@vondra.me> napsal=
:

> On 6/21/25 23:09, Ale=C5=A1 Zelen=C3=BD wrote:
> > Hello,
> > ...
> >
> > The application benefits from parallel queries, so despite the first
> > temptation to disable parallel queries (based on log entries correlatio=
n
> > only, but is that the root cause?) I did not want to disable parallel
> > queries, if there is another workaround/solution/fix available.
> >
> > Thanks for any hints on how to provide more information if needed, as
> > well as for fix/workaround advice.
> >
>
> Could it be that you simply ran out of memory, or perhaps hit the
> overcommit? What does sysctl say?
>
>   sysctl vm.overcommit_memory
>
> And what's CommitLimit/Committed_AS in /proc/meminfo? IIRC the shmem is
> counted against the limit, and if the system does not have significant
> swap, it's not uncommon to hit that (esp. with overcommit_memory=3D2).
>
>
> regards
>
> --
> Tomas Vondra
>
>

--000000000000538cb3063839e537
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div>Thanks for the good point:</div><div><b=
r></div><div>$ sysctl vm.overcommit_memory<br>vm.overcommit_memory =3D 0</d=
iv><div><br></div><div>That is a difference, the old pg11 running on Ubuntu=
 18.4 had disabled=C2=A0overcommit=C2=A0 (vm.overcommit_memory =3D 2).</div=
><div><br></div><div>Anyway, on a dedicated DB server box with 123GB RAM ru=
nning only vacuum (14 parallel processes (2GB maintenance workmen)) and sha=
red buffers 22GB seems to me unlikely to hit available memory.</div><div><b=
r></div><div>During Sunday (low load) and Monday so far, it has not reoccur=
red.</div><div><br></div><div>Kind regards Ales Zeleny</div></div><br><div =
class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail=
_attr">ne 22. 6. 2025 v=C2=A00:44 odes=C3=ADlatel Tomas Vondra &lt;<a href=
=3D"mailto:tomas@vondra.me">tomas@vondra.me</a>&gt; napsal:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">On 6/21/25 23:09, Ale=C5=A1 Zel=
en=C3=BD wrote:<br>
&gt; Hello,<br>
&gt; ...<br>
&gt;<br>
&gt; The application benefits from parallel queries, so despite the first<b=
r>
&gt; temptation to disable parallel queries (based on log entries correlati=
on<br>
&gt; only, but is that the root cause?) I did not want to disable parallel<=
br>
&gt; queries, if there is another workaround/solution/fix available.<br>
&gt; <br>
&gt; Thanks for any hints on how to provide more information if needed, as<=
br>
&gt; well as for fix/workaround advice.<br>
&gt; <br>
<br>
Could it be that you simply ran out of memory, or perhaps hit the<br>
overcommit? What does sysctl say?<br>
<br>
=C2=A0 sysctl vm.overcommit_memory<br>
<br>
And what&#39;s CommitLimit/Committed_AS in /proc/meminfo? IIRC the shmem is=
<br>
counted against the limit, and if the system does not have significant<br>
swap, it&#39;s not uncommon to hit that (esp. with overcommit_memory=3D2).<=
br>
<br>
<br>
regards<br>
<br>
-- <br>
Tomas Vondra<br>
<br>
</blockquote></div>

--000000000000538cb3063839e537--