[ClusterLabs] Antw: Re: Antw: [EXT] unexpected fenced node and promotion of the new master PAF ‑ postgres

[Jehan-Guillaume de Rorthais]

On Tue, 12 Oct 2021 08:42:49 +0200
"Ulrich Windl" <Ulrich.Windl at rz.uni-regensburg.de> wrote:

> ...
> >> sysctl ‑a | grep dirty
> >> vm.dirty_background_bytes = 0
> >> vm.dirty_background_ratio = 10  
> > 
> > Considering your 256GB of physical memory, this means you can dirty up to 
> > 25GB
> > pages in cache before the kernel start to write them on storage.
> > 
> > You might want to trigger these background, lighter syncs much before 
> > hitting
> > this limit.
> >   
> >> vm.dirty_bytes = 0
> >> vm.dirty_expire_centisecs = 3000
> >> vm.dirty_ratio = 20  
> > 
> > This is 20% of your 256GB physical memory. After this limit, writes have to
> > go to disks, directly. Considering the time to write to SSD compared to
> > memory and the amount of data to sync in the background as well (52GB),
> > this could be very painful.  
> 
> Wowever (unless doing really large commits) databases should flush buffers
> rather frequently, so I doubt database operations would fill the dirty buffer
> rate.

It depends on you database setup, your concurrency, your active dataset, your
query profile, batch, and so on.

> "watch cat /proc/meminfo" could be your friend.

Or even better, make sure you have sysstat or pcp tools family installed and
harvesting system metrics. You'll have the full historic of the dirty pages
variations during the day/week/month.