Re: CURRENT slow and shaky network stability

From: Don Lewis <truckman_at_FreeBSD.org>
Date: Sat, 26 Mar 2016 14:26:45 -0700 (PDT)
On 26 Mar, Michael Butler wrote:
> -current is not great for interactive use at all. The strategy of
> pre-emptively dropping idle processes to swap is hurting .. big time.
> 
> Compare inactive memory to swap in this example ..
> 
> 110 processes: 1 running, 108 sleeping, 1 zombie
> CPU:  1.2% user,  0.0% nice,  4.3% system,  0.0% interrupt, 94.5% idle
> Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free
> Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse
> 
>   PID USERNAME       THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU
> COMMAND
>  1819 imb              1  28    0   213M 11284K select  1 147:44   5.97%
> gkrellm
> 59238 imb             43  20    0   980M   424M select  0  10:07   1.92%
> firefox
> 
>  .. it shouldn't start randomly swapping out processes because they're
> used infrequently when there's more than enough RAM to spare ..

I don't know what changed, and probably something can use some tweaking,
but paging out idle processes isn't always the wrong thing to do.  For
instance if I'm using poudriere to build a bunch of packages and its
heavy use of tmpfs is pushing the machine into many GB of swap usage, I
don't want interactive use like:
	vi foo.c
	cc foo.c
	vi foo.c
to suffer because vi and cc have to be read in from a busy hard drive
each time while unused console getty and idle sshd processes in a bunch
of jails are still hanging on to memory even though they haven't
executed any instructions since shortly after the machine was booted
weeks ago.

> It also shows up when trying to reboot .. on all of my gear, 90 seconds
> of "fail-safe" time-out is no longer enough when a good proportion of
> daemons have been dropped onto swap and must be brought back in to flush
> their data segments :-(

That's a different and known problem.  See:
<https://svnweb.freebsd.org/base/releng/10.3/bin/csh/config_p.h?revision=297204&view=markup>
Received on Sat Mar 26 2016 - 20:26:55 UTC

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