Обсуждение: postgres in swap space
hello,
Can someone point me to any doc describing why and how much space postgres uses on the swap of a debian machine ?
it's an old postgres 10, because it is used by a product for which only this version is certified.
(no comment on that, please)
regards
On Mon, Nov 17, 2025 at 12:25 PM Marc Millas <marc.millas@mokadb.com> wrote:
hello,Can someone point me to any doc describing why and how much space postgres uses on the swap of a debian machine ?it's an old postgres 10, because it is used by a product for which only this version is certified.(no comment on that, please)
Swap as in RAM swap space? If so, then it uses as much or as little as Linux thinks needs to be used, given the amount of RAM.
effective_cache_size, work_mem, shared_buffers, maintenance_work_mem, max_worker_* and max_parallel_* affect how much RAM PG uses, in conjunction with the number of active connections (including maintenance work).
https://postgresqlco.nf/doc/en/param/ is a handy resource.
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
Putting memory pages to swap is the decision of the linux virtual memory manager not postgres. If your db machine is swapping, first make sure you have set sensible values for the ram related settings like shared_buffers (25%), effective_cache_size (75%) and work_mem (keep it modest at 4 to 16 MB).
On 11/17/25 12:25 PM, Marc Millas - marc.millas at mokadb.com wrote:
hello,Can someone point me to any doc describing why and how much space postgres uses on the swap of a debian machine ?it's an old postgres 10, because it is used by a product for which only this version is certified.(no comment on that, please)regards
-- regards, Kiriakos Georgiou
On Mon, 2025-11-17 at 18:25 +0100, Marc Millas wrote: > Can someone point me to any doc describing why and how much space postgres uses on the swap of a debian machine ? > it's an old postgres 10, because it is used by a product for which only this version is certified. > (no comment on that, please) I'm biting down a comment. PostgreSQL itself doesn't use any swap space. The kernel can decide to swap out memory used by PostgreSQL. How much that is depends on how you configured the Linux kernel and how much memory PostgreSQL uses. The latter is mostly determined by "shared_buffers", "work_mem", "maintenance_work_mem" and "max_connections". On the kernel side, it is mostly the "vm.swappiness" parameter that determines how eager the kernel is to swap out memory, even if there is no pressure. For best performance, that should happen as little as possible, and the database should determine what to keep in memory and what to store on disk. One tool you have to prevent shared buffers from being swapped out is to define enough Linux hugepages, so that PostgreSQL can allocate shared buffers there. Linux does not swap out hugepages. You can find the PostgreSQL parameters described in the PostgreSQL documentation and the kernel parameters in the kernel documentation. Yours, Laurenz Albe
On Mon, Nov 17, 2025 at 3:50 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Mon, 2025-11-17 at 18:25 +0100, Marc Millas wrote:
> Can someone point me to any doc describing why and how much space postgres uses on the swap of a debian machine ?
> it's an old postgres 10, because it is used by a product for which only this version is certified.
> (no comment on that, please)
I'm biting down a comment.
"If it ain't broke, don't fix it" works just fine (until it doesn't).
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
On 11/17/25 13:12, Ron Johnson wrote: > On Mon, Nov 17, 2025 at 3:50 PM Laurenz Albe <laurenz.albe@cybertec.at > <mailto:laurenz.albe@cybertec.at>> wrote: > > On Mon, 2025-11-17 at 18:25 +0100, Marc Millas wrote: > > Can someone point me to any doc describing why and how much space > postgres uses on the swap of a debian machine ? > > it's an old postgres 10, because it is used by a product for > which only this version is certified. > > (no comment on that, please) > > I'm biting down a comment. > > > "If it ain't broke, don't fix it" works just fine (until it doesn't). The problem is when it doesn't work anymore, the work load to move to a newer version is that much greater. Keeping the version within spitting distance of the latest supported version, to me, is a good idea. > > -- > Death to <Redacted>, and butter sauce. > Don't boil me, I'm still alive. > <Redacted> lobster! -- Adrian Klaver adrian.klaver@aklaver.com
On Mon, Nov 17, 2025 at 4:41 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 11/17/25 13:12, Ron Johnson wrote:
> On Mon, Nov 17, 2025 at 3:50 PM Laurenz Albe <laurenz.albe@cybertec.at
> <mailto:laurenz.albe@cybertec.at>> wrote:
>
> On Mon, 2025-11-17 at 18:25 +0100, Marc Millas wrote:
> > Can someone point me to any doc describing why and how much space
> postgres uses on the swap of a debian machine ?
> > it's an old postgres 10, because it is used by a product for
> which only this version is certified.
> > (no comment on that, please)
>
> I'm biting down a comment.
>
>
> "If it ain't broke, don't fix it" works just fine (until it doesn't).
The problem is when it doesn't work anymore, the work load to move to a
newer version is that much greater.
That's my point. If it just kept working, there would be no problem.
Keeping the version within spitting
distance of the latest supported version, to me, is a good idea.
As much as people love to complain about how useless PCI DSS is (see the recent thread on TDE), there's one benefit: ensuring that companies keep computers patched and running supported software.
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
On Mon, Nov 17, 2025 at 09:49:59PM +0100, Laurenz Albe wrote:
> On Mon, 2025-11-17 at 18:25 +0100, Marc Millas wrote:
> > Can someone point me to any doc describing why and how much space postgres uses on the swap of a debian machine ?
> > it's an old postgres 10, because it is used by a product for which only this version is certified.
> > (no comment on that, please)
>
> I'm biting down a comment.
>
> PostgreSQL itself doesn't use any swap space.
>
> The kernel can decide to swap out memory used by PostgreSQL. How much that is depends
> on how you configured the Linux kernel and how much memory PostgreSQL uses. The latter
> is mostly determined by "shared_buffers", "work_mem", "maintenance_work_mem" and
> "max_connections".
I wrote a blog entry about swap space:
https://momjian.us/main/blogs/pgblog/2012.html#July_25_2012
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
On Mon, Nov 17, 2025 at 9:50 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Mon, 2025-11-17 at 18:25 +0100, Marc Millas wrote:
> Can someone point me to any doc describing why and how much space postgres uses on the swap of a debian machine ?
> it's an old postgres 10, because it is used by a product for which only this version is certified.
> (no comment on that, please)
I'm biting down a comment.
PostgreSQL itself doesn't use any swap space.
The kernel can decide to swap out memory used by PostgreSQL. How much that is depends
on how you configured the Linux kernel and how much memory PostgreSQL uses. The latter
is mostly determined by "shared_buffers", "work_mem", "maintenance_work_mem" and
"max_connections".
On the kernel side, it is mostly the "vm.swappiness" parameter that determines how
eager the kernel is to swap out memory, even if there is no pressure. For best
performance, that should happen as little as possible, and the database should
determine what to keep in memory and what to store on disk.
One tool you have to prevent shared buffers from being swapped out is to define enough
Linux hugepages, so that PostgreSQL can allocate shared buffers there. Linux does not
swap out hugepages.
You can find the PostgreSQL parameters described in the PostgreSQL documentation and the
kernel parameters in the kernel documentation.
Yours,
Laurenz Albe