Re: CURRENT: why is CURRENT swapping so fast?

From: Matthias Andree <matthias.andree_at_gmx.de>
Date: Thu, 12 Jun 2014 02:21:54 +0200
Am 12.06.2014 00:36, schrieb O. Hartmann:
> 
> 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 opened 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 swapping. As of
> today - updating CURRENT (buildword) and also updating ports. Nothing else except
> firefox. And the box is using 1% swapspace.

Are you using ZFS, and more to the point, did you recently start using it?

Do you mean "start swapping out sooner than it used to do"?

Do you expect that swap remains at 0 unless there is serious memory
pressure?

One point: Linux rolls dice when it needs memory, with a tunable that
states the chance that either a cached page gets evicted, or an in-use
page gets swapped out.

Has FreeBSD similar mechanisms these days?

> There are some strange behaviours when compiling ports or the OS itself sometimes. 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 and 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 it works. It
> seems I can not reproduce this problem either. It occurs on 11.0-CURRENT since a couple
> of weeks by now and affects different hardware types (as with the unspecific swapping
> experience mentioned above, either 8GB and 32GB, but it occurs on the 8GB bixes much more
> often than on the 32GB system).

Given memory checks did not turn up anything: Are you sure that
case/memory/chipset/CPU cooling are still intact and not hindered by dust?
Received on Wed Jun 11 2014 - 22:22:03 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:49 UTC