From owner-freebsd-current@FreeBSD.ORG Wed Jun 11 22:36:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A34A132 for ; Wed, 11 Jun 2014 22:36:20 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 185022F10 for ; Wed, 11 Jun 2014 22:36:20 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1Wur7x-000I76-OH>; Thu, 12 Jun 2014 00:36:17 +0200 Received: from g229125000.adsl.alicedsl.de ([92.229.125.0] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1Wur7x-0025Oc-Ki>; Thu, 12 Jun 2014 00:36:17 +0200 Date: Thu, 12 Jun 2014 00:36:12 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: CURRENT: why is CURRENT swapping so fast? Message-ID: <20140612003612.25cc2851.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/0EQWT/KWJM_Bk5qlg0//yF8"; protocol="application/pgp-signature" X-Originating-IP: 92.229.125.0 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 22:36:20 -0000 --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--