Date: Sat, 4 Jul 2020 09:39:38 +1000 From: Peter Jeremy <peter@rulingia.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: <20200703233938.GB30039@server.rulingia.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
--fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-Jul-03 15:44:33 -0700, bob prohaska <fbsd@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. "Swap in use" relates to memory that has been pushed out to the swap device and not referenced since. There can be both lots of swap used and lots of free memory if the system has been under memory pressure (eg a large process) in the past but isn't now. The system will not move data from swap back into RAM unless it's referenced. A typical FreeBSD system will have lots of mostly idle processes and it's fairly normal for them to get paged out. > The swap device is saturated. > >Here's snippet of top output: > >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 That shows page in only - so the system is trying to get data out of swap to fill the free memory. And >1MBps means it's not stuck. >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 The "every few minutes ... one core reaches 100%" implies that every few minutes one process manages to get hold of enough RAM to work through a compiling a file. That process then exits and all the RAM it was using returns to the free pool. >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. I don't think so. The default "run one build process per core" assumes that there's adequate RAM. It's really difficult for the build process to know how big a process will get, and so automatically cut back on the number of parallel processes it spawns. This is one case where I don't believe there is any alternative to manually specifying "-j1" or equivalent. Note that Chromium is a massive chunk of code. A more normal build environment would be several dozen quite fast cores with around 3GB RAM per core. You are really stressing the VM system by trying to build it with ~256MB/core. No. =20 >Looking at man tuning revealed nothing I recognized as relevant.=20 > >Thanks for reading! > >bob prohaska > >_______________________________________________ >freebsd-arm@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-arm >To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Peter Jeremy --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE2M6l8vfIeOACl4uUHZIUommfjLIFAl7/wa9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQ4 Q0VBNUYyRjdDODc4RTAwMjk3OEI5NDFEOTIxNEEyNjk5RjhDQjIACgkQHZIUommf jLKfQA/+JATJK6hQSEq2hLAH+dWaNfdDh8ML6ivc5KTlFJAuBtl0x5Mi3x1qu74z 9cYroDwJJIfjLRS28allmf9NPMKLlx0OXNSVnieF2eNglJaH9Pk9wWwJDdn28rYK k/quWwFUVCZaMO7KQhwFrWKBKMGCna+OMgu9mX4TKA1SdmBpy45QDHBwbubl+m18 TdkMbkZCgEEunAUFwLrpW55W5FD+GWzNsXMbcGs/YlqBNzBHPhsjKTp1OR57Xd2L +8xhGMPodWoT08DW4mGbyI53hbvTdIQkUyZjhgHrFy5hhHOQN80WjgKyUrXBRCBD ldMsei9Jn6E4rd5FzVgX7XVIAR4q9u0ih4ZlQ/l52XaqItMcbYc970XHo/bqjINP nUXEfz1syWs8ZxXCgtXDEVeI3dwnVoPzg5flIWbnH3lW9jsz8NAtZ6/tCAz7XfGU R7rJ3KhgATQdOKuYgcXyYWvXlq88hW3ymNrm/oIDj84aKIBkwapQ3nosvzwoJfRo kLuEoere9om0amVeSAR6xX5ENsK/NScR9jEd5NAMBW10IgxJj6P/qYA7MwpaPIYy iVOw3Q+K6Y8gjWVRBYs7eYY/rkeHkstW2pKUNT2IU3O3PBxXP1dXeucQYRJSJ1Dz gyKo5oPabQuBfohvEOKMu34cHP+7FZ17Qn5YL26pF94ID5Z4xs0= =h6NF -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200703233938.GB30039>