Re: Safe vm.overcommit_ratio for Large Multi-Instance PostgreSQL Fleet - Mailing list pgsql-performance

From Joe Conway
Subject Re: Safe vm.overcommit_ratio for Large Multi-Instance PostgreSQL Fleet
Date
Msg-id 7fd9f434-e0d9-414b-b396-841ad3c00040@joeconway.com
Whole thread Raw
In response to Re: Safe vm.overcommit_ratio for Large Multi-Instance PostgreSQL Fleet  (Frits Hoogland <frits.hoogland@gmail.com>)
Responses Re: Safe vm.overcommit_ratio for Large Multi-Instance PostgreSQL Fleet
List pgsql-performance
On 8/6/25 17:14, Frits Hoogland wrote:
>> As I said, do not disable swap. You don't need a huge amount, but
>> maybe 16 GB or so would do it.

> Joe, please, can you state a technical reason for saying this?
> All you are saying is ‘don’t do this’.
> 
> I’ve stated my reasons for why this doesn’t make sense, and you don’t give any reason.

What do you call the below?

>> Op 6 aug 2025 om 18:33 heeft Joe Conway <mail@joeconway.com> het volgende geschreven:

>> * Swap is what is used when anonymous memory must be reclaimed to
>> allow for an allocation of anonymous memory.
>> 
>> * The Linux kernel will aggressively use all available memory for
>> file buffers, pushing usage against the limits.
>> 
>> * Especially in the older 4 series kernels, file buffers often
>> cannot be reclaimed fast enough
>> 
>> * With no swap and a large-ish anonymous memory request, it is
>> easy to push over the limit to cause the OOM killer to strike.
>> 
>> * On the other hand, with swap enabled anon memory can be
>> reclaimed giving the kernel more time to deal with file buffer
>> reclamation.
>> 
>> At least that is what I have observed.

If you don't think that is adequate technical reason, feel free to 
ignore my advice.

-- 
Joe Conway
PostgreSQL Contributors Team
Amazon Web Services: https://aws.amazon.com



pgsql-performance by date:

Previous
From: Frits Hoogland
Date:
Subject: Re: Safe vm.overcommit_ratio for Large Multi-Instance PostgreSQL Fleet
Next
From: Frits Hoogland
Date:
Subject: Re: Safe vm.overcommit_ratio for Large Multi-Instance PostgreSQL Fleet