Date: Sun, 18 Nov 2018 14:05:04 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Stefan Blachmann <sblachmann@gmail.com> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, Mark Millard <marklmi@yahoo.com>, Rebecca Cran <rebecca@bluestop.org>, freebsd-hackers Hackers <freebsd-hackers@freebsd.org>, Mark Johnston <markj@freebsd.org>, Ian Lepore <ian@freebsd.org>, Wojciech Puchar <wojtek@puchar.net> Subject: Re: 13-CURRENT: several GB swap being used despite plenty of free RAM Message-ID: <201811182205.wAIM543W036241@slippy.cwsent.com> In-Reply-To: Message from Stefan Blachmann <sblachmann@gmail.com> of "Sun, 18 Nov 2018 13:11:49 %2B0100." <CACc-My33oRg7eqjfDuEQU51inyydc66Hx%2B-DysqmdKyyMVVJsA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <CACc-My33oRg7eqjfDuEQU51inyydc66Hx+-DysqmdKyyMVVJsA@mail.gma il.com> , Stefan Blachmann writes: > The inconveniences that the new swapping strategy causes are a regular > topic in the FreeBSD forums. > > Desktop users complain about lagginess, server users complain of long > delays because server processes intended to be kept in memory for > quick response times got swapped out and need to be swapped in again, > resulting in outrageously poor server performance in spite of plenty > of unused memory. There are many factors for this. One of the biggest mistakes people make is use UFS and ZFS on the same system. Limiting ZFS ARC max would be a good place to start. Unfortunately like many operating systems these days, FreeBSD's tuning parameters are generally baked in. And, fencing (an IBM term to limit address space memory use or to establish a minimum) isn't available. So, tuning for a site specific workload is more difficult. Making sure there is plenty of RAM installed and tuning down ZFS ARC can go a long way. Having said that, it's been a while since I've had to do this. The updates made to ZFS ARC and NUMA have allowed me to rely on the algorithms baked into FreeBSD. My 8 GB systems have performed rather well. > > Turning off swap completely, as Cy Schubert suggests, is strongly > discouraged in the forums, as it can lead to kernel panicking because > of being unable to swap out in critical kernel memory shortage > situations, leading to the risk of very serious filesystem > corruption. Actually, I didn't suggest it. I simply pointed out the option. Furthermore, it was a mistake for Linux to remove swapping entirely from their kernel. For those who want to try it, however, the option is there. > > However, Cy Schubert is probably right when stating that the new > swapping strategy resembles the 1960s-1980s industry's main swapping > strategy. > The bad thing is now, that nowadays memory is no longer scarce and > people can dimension their memory such that under normal circumstances > there will never be any need to swap. Adding more RAM has been the general thinking over the last 15-20 years. > > So I guess the unwillingness of the developer team to add an option > like "NoPreemptiveSwapping", which disables swapping out as long as > there is free physical memory available, is of psychological nature. How do you know processes are indeed swapped out rather than (many) pages paged out. You can't tell and using top's w mode, sorted by swap doesn't tell us anything because IMO it's bogus, incorrect numbers. > > Lacking such an option, there is still the possibility to use rctl to > disable swapping for particular users, processes, jails etc to > mitigate the problems caused by the new swapping strategy to some > degree. Our options are limited. I'd prefer something similar to what we had on MVS, when I worked on it, however even IBM has dumbed down SRM (System Resource Manager) such that knobs that were once there no longer are. Tuning based upon analysis of site specific stats are a thing of the past. It's 2018 and sadly one size fits all. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201811182205.wAIM543W036241>