2000-12-12 22:40:19

by Jussi Laako

[permalink] [raw]
Subject: VM problem (2.4.0-test11)

Hello,

Would it be possible to implement some VM CPUtime/bandwidth limitation?

We have server used by multiple developers. Problem is when someone happens
to implement memory hole to application the system goes wild swapping and
ALL other activity stops. No response to keyboard/mouse events nor any
network traffic. Only disk system running wildly. No way to stop the
memoryhog application, only way out of this situation is to hit reset-button
and hope that no important data is lost. Same thing happens when I forget to
end some large matrix operation with semicolon in Octave... (and 2.2.x
kernels at least with Octave) I'm still considering this as local DOS attack
because normal user is able to overload the system.

Rebooting system all the time is annoying.

It would be nice to be able to tell system that "this process may use max
256 MB of memory and 10% of disk IO bandwidth and 25% of network bandwidth
and network IO latency is critical and disk io is not".

Kernel is stock except Andrew Morton's lowlatency patch.

Regards,

- Jussi Laako

--
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B
Available at: ldap://certserver.pgp.com, http://keys.pgp.com:11371


2000-12-12 23:31:48

by Marc Mutz

[permalink] [raw]
Subject: Re: VM problem (2.4.0-test11)

Jussi Laako wrote:
>
> Hello,
>
> Would it be possible to implement some VM CPUtime/bandwidth limitation?
>
<snip>

Just to not miss the obvious: You know about ulimit(3)?

man 3 ulimit
help ulimit (when in bash).

Marc

--
Marc Mutz <[email protected]> http://EncryptionHOWTO.sourceforge.net/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)

2000-12-12 23:56:26

by Jussi Laako

[permalink] [raw]
Subject: Re: VM problem (2.4.0-test11)

Marc Mutz wrote:
>
> Just to not miss the obvious: You know about ulimit(3)?

Yes, but it doesn't stop deadlocks caused by kernel's VM system going
wild... I think that no matter what user process does, root should be always
able to stop it. User process should never be able to render whole system
unusable.

Hard memory limit per process doesn't stop this from happening, because it
depends overall system memory usage and allocation rate. It's completely
different if memory usage goes from 200 MB to 512 MB in 1 usec or 1 week.

- Jussi Laako

--
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B
Available at PGP keyservers

2000-12-13 00:12:11

by J.A. Magallon

[permalink] [raw]
Subject: Re: VM problem (2.4.0-test11)


On Wed, 13 Dec 2000 00:25:25 Jussi Laako wrote:
> Marc Mutz wrote:
> >
> > Just to not miss the obvious: You know about ulimit(3)?
>
> Yes, but it doesn't stop deadlocks caused by kernel's VM system going
> wild... I think that no matter what user process does, root should be always
> able to stop it. User process should never be able to render whole system
> unusable.
>

That is just some issue that was discussed in this list recently. Look in the
list
for 'oom killer' subjects.
There are various patches-ways-to-do available, kernel gurus are still working
on it...
(leave always some 4% of mem for root, kill some process when mem is exhausted,
which one to kill...)

--
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[email protected] #> more beer

Linux werewolf 2.2.18-aa1 #1 SMP Mon Dec 11 21:26:28 CET 2000 i686

2000-12-14 09:50:59

by Ragnar Hojland Espinosa

[permalink] [raw]
Subject: Re: VM problem (2.4.0-test11)

On Wed, Dec 13, 2000 at 12:41:19AM +0100, J . A . Magallon wrote:
> There are various patches-ways-to-do available, kernel gurus are still working
> on it...
> (leave always some 4% of mem for root, kill some process when mem is exhausted,
> which one to kill...)

which is a bad idea; 4% of 1GB is a waste, and 4% of 8mb is really pushing
it (that is, if we are speaking about root just doing cleanup stuff)

--
____/| Ragnar H?jland Freedom - Linux - OpenGL Fingerprint 94C4B
\ o.O| 2F0D27DE025BE2302C
=(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822
U chaos and madness await thee at its end." hkp://keys.pgp.com

Handle via comment channels only.