Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Jun 2014 00:36:12 +0200
From:      "O. Hartmann" <ohartman@zedat.fu-berlin.de>
To:        FreeBSD CURRENT <freebsd-current@freebsd.org>
Subject:   CURRENT: why is CURRENT swapping so fast?
Message-ID:  <20140612003612.25cc2851.ohartman@zedat.fu-berlin.de>

next in thread | raw e-mail | index | archive | help
--Sig_/0EQWT/KWJM_Bk5qlg0//yF8
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable


I use my boxes for daily work and in most cases, the usage of applications =
is the same.
Compiling the OS and updating ports while having claws-mail and firefox ope=
ned is some
usual scenario.

I realise since a couple of weeks, if not months now, but always sticky to =
11.0-CURRENT,
that the system is even with 8 GB RAM very quickly out of memory and swappi=
ng. As of
today - updating CURRENT (buildword) and also updating ports. Nothing else =
except
firefox. And the box is using 1% swapspace.

It is hard to reproduce or give exact numbers or any more scientific values=
. But the way
I do my work is monotonic and it is more than obvious that the box is swapp=
ing much
faster right now than, say, 6 months ago. The problem occurs on different h=
ardware types,
one box has 8 GB, the other 32GB.

There are some strange behaviours when compiling ports or the OS itself som=
etimes. I very
often linker errors with something like

[...] relocation truncated to fit: R_X86_64_PC32 [...]

This strange behaviour sometimes occurs immediately I switched on the box a=
nd start
updating and building world (nothing else done so far) or updating a port. =
When this
error occurs, I reboot and do the very same job again - and then suddenly i=
t works. It
seems I can not reproduce this problem either. It occurs on 11.0-CURRENT si=
nce a couple
of weeks by now and affects different hardware types (as with the unspecifi=
c swapping
experience mentioned above, either 8GB and 32GB, but it occurs on the 8GB b=
ixes much more
often than on the 32GB system).

I'm sorry about this unspecific reporting, but since I observe this strange=
 behaviour but
can not successfully reproduce it by will I suspect something "faulty". I d=
id already RAM
checks on the systems affected - without any abnormal occurence of memory f=
aults or so.

Regards,
oh

--Sig_/0EQWT/KWJM_Bk5qlg0//yF8
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

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

iQEcBAEBAgAGBQJTmNnhAAoJEOgBcD7A/5N8d/cIAIc6aXFnw1qxEmIShJFu9Y8U
s+iPVcgOUdgwcsPEn6oD5afwlDGNKopiTQiw1vcP2LhCkpshJ2IlJugsdbzXRXZa
dqj/E5DN8TOAh6Uhb6Mv50QvXgi4JlBqiayj1dFhy++7yMwbiB3+e9QenT8fHyfj
Qb8jkQHzzG2cKlStgKkcrkQ3Tc6hKpTitakb8CnF/x+LNpJimX42x4icDygDvAum
w2bbxiYldg8U1EoOd4oIpq/FN6sV4X2UpkV1MWlR6uXn1bUXClEh4Xlja8fafgdj
mtjmVGI4OfdkCpvzlfiCkbnN12RYdrJun7veWlQ2vH7s/fb72t3Z7RF+RI7niWo=
=C+7X
-----END PGP SIGNATURE-----

--Sig_/0EQWT/KWJM_Bk5qlg0//yF8--



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