Re: CURRENT slow and shaky network stability

From: Ultima <ultima1252_at_gmail.com>
Date: Sat, 26 Mar 2016 18:51:11 -0400
 Having this long timeout issue occur many times during the day.  Normally
not this bad, currently on r297060 amd64. A few hours ago had a system hang
that lasted for about 1-2 hours.(not sure how long exactly, gave up
waiting) It occured after a zfs destroy operation and affected sshd. (could
no longer login via ssh) The system was in a seemingly unusable state
during this time.

 A large zfs send was underway during the outage. This operation was not in
the same state as the system receiving was still growing.

Not sure if its related, sounds like it is. Any more information that maybe
helpful?

On Sat, Mar 26, 2016 at 5:26 PM, Don Lewis <truckman_at_freebsd.org> wrote:

> 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
> >
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
Received on Sat Mar 26 2016 - 21:51:13 UTC

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