On Tue, 12 Oct 2021 08:42:49 +0200 "Ulrich Windl" <ulrich.wi...@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. _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
