Runaway processes freeze the system

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Runaway processes freeze the system

Yuri-10
I am getting this problem again and again: when some process allocates
too much memory the system to freezes.

My memory size is 24GB, and swap is only 4GB. I know that increasing the
swap size should reduce the chance of this happening, but it obviously
can't eliminate the problem.


What is the expected behavior of the system in such situation? To me it
looks like it is wait-and-see, and this causes this problem.

A better strategy would be to maybe wait for some time, but if when the
problem persists to kill the largest, the most active, or the offending
process.


11.1 amd64


Yuri


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Runaway processes freeze the system

Stefan Blachmann
Ideally rctl(8) should be the solution.
Actions can be defined to refuse to allocate more memory or kill
processes that demand too much memory.

By turning off swap and restricting memory usage one can improve
performance by preventing the swapper making the system sluggish.

However, rctl is only of limited use for desktop users, as Xorg fails
to start if vmemoryuse gets restricted (no matter how big the value).
So rctl(8) appears of practical use only for example for protecting
servers and embedded systems from crashing and damaging filesystems
because of user programs eating up too much memory.

I advise you to experiment with it, as the rctl(8) documentation/man
page seems partly incorrect/misleading, for example regarding per-user
resource limiting.

On 4/20/18, Yuri <[hidden email]> wrote:

> I am getting this problem again and again: when some process allocates
> too much memory the system to freezes.
>
> My memory size is 24GB, and swap is only 4GB. I know that increasing the
> swap size should reduce the chance of this happening, but it obviously
> can't eliminate the problem.
>
>
> What is the expected behavior of the system in such situation? To me it
> looks like it is wait-and-see, and this causes this problem.
>
> A better strategy would be to maybe wait for some time, but if when the
> problem persists to kill the largest, the most active, or the offending
> process.
>
>
> 11.1 amd64
>
>
> Yuri
>
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Runaway processes freeze the system

Rozhuk Ivan-2
On Fri, 20 Apr 2018 21:17:41 +0200
Stefan Blachmann <[hidden email]> wrote:

> Ideally rctl(8) should be the solution.
> Actions can be defined to refuse to allocate more memory or kill
> processes that demand too much memory.
>

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195882

I do not try it with 11.1, but rctl will not help for this case.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Runaway processes freeze the system

Yuri-10
In reply to this post by Stefan Blachmann
On 04/20/18 12:17, Stefan Blachmann wrote:

> Ideally rctl(8) should be the solution.
> Actions can be defined to refuse to allocate more memory or kill
> processes that demand too much memory.
>
> By turning off swap and restricting memory usage one can improve
> performance by preventing the swapper making the system sluggish.
>
> However, rctl is only of limited use for desktop users, as Xorg fails
> to start if vmemoryuse gets restricted (no matter how big the value).
> So rctl(8) appears of practical use only for example for protecting
> servers and embedded systems from crashing and damaging filesystems
> because of user programs eating up too much memory.
>
> I advise you to experiment with it, as the rctl(8) documentation/man
> page seems partly incorrect/misleading, for example regarding per-user
> resource limiting.


I am trying to understand what happens when both memory and swap are
completely exhausted, and some process still tries to allocate more.
This process calls mmap, but it can't succeed. There are only a few
things that the kernel can do: 1. wait in a hope that some other process
will return some memory soon 2. fail mmap 3. kill some process to free
memory.


It seems like the current behavior is to wait indefinitely. First one
large offending process freezes. Then other, smaller processes that
attempt to allocate some more memory also freeze, one by one, and the
whole system becomes unusable. I am trying to understand why this
behavior occurs, instead of options 2 or 3? Are there any relevant
sysctl variables? Is this a conscious choice of behavior? Is there some
malfunction involved, and this isn't the intended behavior?


Yuri


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Runaway processes freeze the system

Wojciech Puchar-8
In reply to this post by Yuri-10
> size should reduce the chance of this happening, but it obviously can't
> eliminate the problem.
>
>
> What is the expected behavior of the system in such situation? To me it looks
> like it is wait-and-see, and this causes this problem.
>
> A better strategy would be to maybe wait for some time, but if when the
> problem persists to kill the largest, the most active, or the offending
> process.
>
>
> 11.1 amd64
it's better to have more swap than memory.
second it's good to use ulimit to prevent overallocating memory

you may just edit login.conf and do
cap_mkdb /etc/login.conf

and relogin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"