Date: Fri, 3 Jul 2020 16:27:49 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: 1341MB swap in use with half gig of free memory Message-ID: <69F3DAD2-9BFD-4D74-8E80-E8761E740606@yahoo.com> In-Reply-To: <20200703224433.GA36511@www.zefox.net> References: <20200703224433.GA36511@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Jul-3, at 15:44, bob prohaska <fbsd at www.zefox.net> wrote: > In watching wwwchromium (very) slowly compile on a Pi3 running > r362742-current something strange showed up: It had half a gig=20 > of "free" memory, but still has over a gig of swap in use. The=20 > swap device is saturated. >=20 > Here's snippet of top output: >=20 > last pid: 77187; load averages: 0.56, 0.80, 0.82 = up 4+19:29:15 14:39:56 > 39 processes: 1 running, 38 sleeping > CPU: 0.1% user, 0.0% nice, 0.2% system, 0.1% interrupt, 99.6% idle > Mem: 80M Active, 63M Inact, 3508K Laundry, 176M Wired, 97M Buf, 580M = Free > Swap: 3547M Total, 1341M Used, 2206M Free, 37% Inuse, 1188K In >=20 > It isn't entirely stuck, every few minutes free memory wanders down to=20= > 20MB and one core reaches 100% use, but in general it seems to keep > considerable free memory in preference to reducing swap use. That = would > seem to be unhelpful in this use case. =20 >=20 > The machine has a 1TB mechanical hard disk with a single root = partition > and single swap partition. Make is running without explicit -j value, > and appears to be attempting -j4. Earlier in the build it seemed to be > running more rapidly, but over the last day or so it has gone from = mostly > busy to mostly idle with not much change in swap use. There are no = errors > or warnings on the console, and no complaint about swap quantitiy on = boot. >=20 > Obviously it's possible to use -j or MAX_JOBS_NUMBER, but reluctance = to > keep all memory in use makes me wonder if something else is amiss. > Looking at man tuning revealed nothing I recognized as relevant.=20 I'll remind of past discussions of how long paging out and paging in large mounts of swap/paging content can take. So, say, a process finishes and frees memory and another process starts demand paging in pages that had been paged out and sends most of its time doing that to establish a better sized working set for its large amount of RAM use. Say it tries to page in 512 GiBytes or so, for simplicity. For your combination of devices, how long would that take? Quoting an older message exchange that had old gstat and other information information about the amount of time spent reading and how fast the reading activity was going in such a context: QUOTE > As for being "saturated": >=20 > At 321 KB/s (the example in the gstat output), if it was loading > something large, such as 512 MiBytes, just basically reading that > much material at a mean of such a rate would be over 25 minutes: >=20 > 512*1024*1024_bytes * (1sec/(321*1024_bytes)) * (1minute/(60sec)) >=20 > (Not that I know the 512 MiByte is realistic or that the 321 > KiBYtes/sec is a realistic mean rate.) This just gives an idea > what might be involved and that being beyond seconds or even a > small number of minutes for the general time scale may well be > possible. >=20 > Extensive paging/swapping can vastly slow things down. >=20 That is a startling realization.=20 END QUOTE I'm not saying that 321 KiB/s or so is what you were seeing this time. But seeing how much time is going to read in from the swap/paging device (processes waiting on paging I/O) and what sort of I/O rates it is experiencing for the swapping/paging device(s) (gstat) for the overall effect is relevant information. A way to avoid such issues is to use systems with enough RAM to avoid needing 1341M of swap being in use for the same -jN. Another way is to use a device with better I/O characteristics for the swapping and paging activity, such as avoiding seek times being nearly as large (and more). Or both. As stands you are not just keeping all RAM in use, you are keeping much of the swap/paging space in heavy use as well. Both CPUs and RAM end up waiting on paging/swapping I/O in order to deal with the original memory access requests by programs. Without other details, such generic points are all that I have. But they may point a direction for your activity or your investigations of the issue. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?69F3DAD2-9BFD-4D74-8E80-E8761E740606>