Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Mar 2016 08:44:40 +0200
From:      "O. Hartmann" <ohartman@zedat.fu-berlin.de>
To:        Don Lewis <truckman@FreeBSD.org>
Cc:        imb@protected-networks.net, kmacy@freebsd.org, freebsd-current@freebsd.org
Subject:   Re: CURRENT slow and shaky network stability
Message-ID:  <20160328084440.501ef862.ohartman@zedat.fu-berlin.de>
In-Reply-To: <201603262126.u2QLQjT0079960@gw.catspoiler.org>
References:  <56F6C6B0.6010103@protected-networks.net> <201603262126.u2QLQjT0079960@gw.catspoiler.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/ZQLnfXDjLCouqu4B/uH2Zxc
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Am Sat, 26 Mar 2016 14:26:45 -0700 (PDT)
Don Lewis <truckman@FreeBSD.org> schrieb:

> 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.
> >=20
> > Compare inactive memory to swap in this example ..
> >=20
> > 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
> >=20
> >   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
> >=20
> >  .. it shouldn't start randomly swapping out processes because they're
> > used infrequently when there's more than enough RAM to spare .. =20
>=20
> 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.
>=20
> > 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 :-( =20
>=20
> That's a different and known problem.  See:
> <https://svnweb.freebsd.org/base/releng/10.3/bin/csh/config_p.h?revision=
=3D297204&view=3Dmarkup>

CURRENT has rendered unusable and faulty. Updating ports for poudriere ends=
 up in this
error/broken pipe from remote console:

 [~] poudriere ports -u -p head
[00:00:00] =3D=3D=3D=3D>> Updating portstree "head"
[00:00:00] =3D=3D=3D=3D>> Updating the ports tree... done
root@gate [~] Fssh_packet_write_wait: Connection to 192.168.250.111 port 22=
: Broken pipe


Although not under load, several processes over time gets idled/paged out -=
 and they
never recover, the connection is then sabott, the whole thing unusable :-(

--Sig_/ZQLnfXDjLCouqu4B/uH2Zxc
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJW+NLYAAoJEOgBcD7A/5N8jvEH/iDy2YDTGdVxMibwLTIoJFlr
v+AkV3/VDX9CXRTyeHFdNwHm5bYT333Y7VTXw/h2i1JDuMG1j4yEF28bTBwqR3W1
AwHcjIOjaSLGtIwNO7QmHXcCU47k3RICQysKBllMipFCSdjH7NGebq2AqGAB90Zm
5I+yT1GF2FAwV6FV17yFffk7epehmOcu+jo2XSkgPDINVLoaFQars9a0CoPjhtbu
NKj3iTv3ZqiMbYE5sHLtWtY5cAfrG7sAiHt74v58v2bffs28geczU+vkZWhSdNgz
OM0GUc838zk7IS23Aq+YrZ0J8toROvBGzlwF8uMrgm/XHLU2ohep2vliHd0ZPys=
=SA75
-----END PGP SIGNATURE-----

--Sig_/ZQLnfXDjLCouqu4B/uH2Zxc--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160328084440.501ef862.ohartman>