Re: poudriere, swap full and top says memory is free ?

From: Trev <freebsd-current_at_sentry.org>
Date: Sun, 15 Sep 2019 17:48:51 +1000
Don Lewis wrote on 15/09/2019 11:31:
> On 14 Sep, John-Mark Gurney wrote:
>> Kurt Jaeger wrote this message on Sat, Sep 14, 2019 at 19:38 +0200:
>>> - a poudriere build
>>> - of a list of ports
>>> - on 12.0-RELEASE-p10
>>> - on a 4 core+4 hyperthreads CPU, an Intel(R) Xeon(R) CPU E3-1230 v6
>>>    _at_ 3.50GHz
>>> - with 32 GB RAM
>>> - zpool with 2x 500 GB SSDs as a mirror
>>>
>>> and right now, this can be seen:
>>>
>>> last pid: 90922;  load averages:  5.02,  5.14,  5.73    up 0+03:53:08  19:31:05
>>> 82 processes:  6 running, 76 sleeping
>>> CPU: 60.6% user,  0.0% nice,  2.1% system,  0.0% interrupt, 37.3% idle
>>> Mem: 4598M Active, 2854M Inact, 11G Laundry, 6409M Wired, 6375M Free
>>> ARC: 3850M Total, 1721M MFU, 2090M MRU, 665K Anon, 19M Header, 19M Other
>>>       3406M Compressed, 3942M Uncompressed, 1.16:1 Ratio
>>> Swap: 18G Total, 18G Used, 396K Free, 99% Inuse, 68K In
>>>
>>> So: Swap is full, approx. 6 GB memory is reported as free.
>>>
>>> This is surprising. Can I somehow tune this in any way, so that
>>> the memory available is used for the build ? Or is the problem somewhere
>>> else ?
>>
>> Are you sure that this hasn't just recently completed a large link of
>> something like Chromium?  There are known to be compiles that can take
>> many GB's of memory and if they recently exited, there hasn't been time
>> to swap stuff back in...  or is this the steady state over the entire
>> compile?
> 
> This is sort of an odd case.  I suspect that swap filled and then a
> process that was using a large amount of memory but no swap exited or
> was killed.  That freed a bunch of memory, but no swap.
> 
> I'm pretty sure that when a memory page is paged back in from swap, that
> the copy in swap is retained and not deallocated.  Under memory
> pressure, that allowed the page to be stolen without having to write it
> back out to swap again, unless it was re-dirtied in the meantime.

Don't forget swap fragmentation could conceivably cause oom even if 
there is swap appearing to be available. sysctl vm.swap_fragmentation is 
interesting.
Received on Sun Sep 15 2019 - 05:49:04 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC