Re: CURRENT: why is CURRENT swapping so fast?

[Mark Martinec]

me wrote:

Is this also fixed in the 10.0-STABLE by now?

The situation does not improve by itself, ARC has it all, less
active jobs scramble and fight for whatever free memory is left for
them and most of them remain swapped out. The best curse of action
to recover is to reboot. Quite a pain.


On 2014-06-14 17:29, Matthew D. Fuller wrote:

You may want to check out
 which I
believe is related.  Make sure you get the latest patch rather than
the older one, ref's in comment 10 at
.


Great, thank you, will apply it in the coming days.

One would hope that such a serious pathological behaviour
(in 10-STABLE and 11) would get the patch applied by now
(patch available for two months now, problem described in March),
or the former logic reverted.


I have this patch on a fresh 10.0-STABLE running now for five days,
and things have improved significantly. Inactive processes are still
swapped out, but ARC no longer monopolizes all it can grab, and newly
activated processes get a chance to run quickly. Running a busy
poudriere build no longer leaves the system in unusable state
after it finishes.

I hope this gets rolled into 10.0-STABLE soon.

  Mark
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: why is CURRENT swapping so fast?

[Mark Martinec]

me wrote:
>> Is this also fixed in the 10.0-STABLE by now?
>>

The situation does not improve by itself, ARC has it all, less
active jobs scramble and fight for whatever free memory is left for
them and most of them remain swapped out. The best curse of action
to recover is to reboot. Quite a pain.


On 2014-06-14 17:29, Matthew D. Fuller wrote:

You may want to check out
 which I
believe is related.  Make sure you get the latest patch rather than
the older one, ref's in comment 10 at
.


Great, thank you, will apply it in the coming days.

One would hope that such a serious pathological behaviour
(in 10-STABLE and 11) would get the patch applied by now
(patch available for two months now, problem described in March),
or the former logic reverted.

  Mark



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: why is CURRENT swapping so fast?

[Matthew D. Fuller]

On Sat, Jun 14, 2014 at 01:12:08AM +0200 I heard the voice of
Mark Martinec, and lo! it spake thus:
>
> The situation does not improve by itself, ARC has it all, less
> active jobs scramble and fight for whatever free memory is left for
> them and most of them remain swapped out. The best curse of action
> to recover is to reboot. Quite a pain.

You may want to check out
 which I
believe is related.  Make sure you get the latest patch rather than
the older one, ref's in comment 10 at
.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: why is CURRENT swapping so fast?

[Mark Martinec]

On 2014-06-12 2:26, Steven Hartland wrote:

Also how recent a current there where some vm changes which apparently
helped with this
specifically r260567 and r265944.


Is this also fixed in the 10.0-STABLE by now?

I'm running "10.0-STABLE #0 r266449 May 19" (with ZFS and
16 MB of memory) and I'm noticing pretty much what O. Hartmann
describes (since a couple of weeks or maybe a month ago).

When some bulky operation (like a poudriere build) runs, some
inactive processes are swapped out. This is just fine, but when
the bulky task is finished, the ARC extends to the new released
memory, but the swapped out jobs then struggle for memory
when they become active again. It can take a minute for a
sshd (login from remote) to respond with a prompt, and it can
take long minutes for a swapped out SQL database (not large)
or a web browser to become responsive again. The situation
does not improve by itself, ARC has it all, less active jobs
scramble and fight for whatever free memory is left for them
and most of them remain swapped out. The best curse of action
to recover is to reboot. Quite a pain.

  Mark
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: why is CURRENT swapping so fast?

[Allan Jude]

On 2014-06-11 18:36, O. Hartmann wrote:
> 
> 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.
> 
> 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 
> swapping much
> faster right now than, say, 6 months ago. The problem occurs on different 
> hardware types,
> one box has 8 GB, the other 32GB.
> 
> 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).
> 
> 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 did 
> already RAM
> checks on the systems affected - without any abnormal occurence of memory 
> faults or so.
> 
> Regards,
> oh
> 

What does 'top' show. It probably holds the answer
or top -S -o res


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: CURRENT: why is CURRENT swapping so fast?

[Steven Hartland]

- Original Message - 
From: "Matthias Andree" 




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?


Also how recent a current there where some vm changes which apparently helped 
with this
specifically r260567 and r265944.

   Regards
   Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: why is CURRENT swapping so fast?

[Matthias Andree]

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?

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"