1341MB swap in use with half gig of free memory

[Peter Jeremy]

On 2020-Jul-03 15:44:33 -0700, 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 
>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 
>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.  

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.  

>Looking at man tuning revealed nothing I recognized as relevant. 
>
>Thanks for reading!
>
>bob prohaska
>
>_______________________________________________
>freebsd-arm at freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20200704/23d8eff4/attachment.sig>