Re: Linux as resilient as BSD, resource hogging?
From: John S. Dyson (dyson@iquest.net)Date: 08/03/02
- Next message: Michael Erskine: "Re: Linux as resilient as BSD, resource hogging?"
- Previous message: Stefan Kornexl: "Re: password policy"
- In reply to: Kasper Dupont: "Re: Linux as resilient as BSD, resource hogging?"
- Next in thread: Kasper Dupont: "Re: Linux as resilient as BSD, resource hogging?"
- Reply: Kasper Dupont: "Re: Linux as resilient as BSD, resource hogging?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "John S. Dyson" <dyson@iquest.net> Date: Fri, 2 Aug 2002 18:02:52 -0500
"Kasper Dupont" <kasperd@daimi.au.dk> wrote in message news:3D4AE1DB.4813C5B3@daimi.au.dk...
> Jem Berkes wrote:
> >
> > I know that there are several ways that a regular user can, on a Linux
> > system, disable/crash the system by doing things that use up all available
> > resources. For instance, $0&$0 (using bash), or perl fork bomb -- and
> > ulimit certainly doesn't stop everything.
> >
> > I'm guessing that BSD can withstand such things -- it's more popular among
> > ISPs who have to deal with many, potentially untrustworthy users. Why can't
> > Linux handle these resource hogging issues? What mechanisms are there in
> > BSD that we can add to Linux?
>
> I don't know what BSD does, but I could point out a few things that
> could be done better in Linux. The following ideas is not aimed at
> one particular resource, most of them can be used for all resources.
>
> Ulimit is good, but it does not solve all problems like some people
> tend to claim. We have a limited amount of a resource, and we try
> to manage it by assigning a maximum to each user.
>
One data point: I did fully implement a memory controlling ulimit (admittedly
on a per-process basis) on FreeBSD. This made sure that the resident set
was truly limited, and replaced pages on a working-set model, rather than
global. I ran numerous tests of various algorithms (from complex to simplistic),
and the general result was that adding a hard memory limit (unlike the soft
limit as currently implemented) tended to increase disk traffic enough to cause
an aggregate performance decrease. It is likely possible to mitigate the effect
of the additional memory traffic, but I didn't persue that direction any further.
My goal, over 5yrs ago, in the FreeBSD VM work was to maintain good traditional
UNIX-like behavior, but if the goal would have been biased more towards a
system where resource mgmt would have been needed, it would have taken
ALOT more than a simple VM resident set limit to make the system run better
as an aggregate.
IMO, when the goal of the algorithm (in the sense of memory mgmt) is to
minimize I/O (while supporting the continued runnability of processes), then
the system wide global performance will be maximized. Fairness WRT memory
hogs shouldn't be *solely* managed by a memory limit policy, if that policy
causes additional paging. This MIGHT be a case where a 'swapping' or higher
level scheduling concept could be worthwhile, when the memory hog that naturally
increases the system wide paging rate (either with a memory limit or not) thereby
seriously negatively impacting the performance of other processes, then the
*hog* process would be suspended. The performance would become choppy,
but the paging device resource (response time, transaction rate, transfer rate)
does become problematical.
On FreeBSD, it really does fairly well achieve a stable and apparently near
minimal paging behavior for 'normal' programs and program mixes. However,
it really does have the same kind of natural, pathological behavior, common
to many other OSes, when a single process can demand and force lots of paging
in the system. I tend to think of it like this: if a process is a VM memory hog,
and it forces alot of paging activity (which causes system wide resource
contention), then it is not generally worthwhile to force more paging by limiting
the memory resources available to that process. There might be some cases
where the process can be 'bottled up' and limit the system-wide impact, but
I found that it is pretty clear that a hard memory limit isn't the right answer alone.
The problems with a paging hog need to be considered WRT to paging latencies
as well as the memory hog program itself. Paging latencies can be helped a little
bit by allowing fewer (perhaps one) program to be runnable and competitive for
memory at any given time. This can make the system very choppy, and is (of course)
not a general solution. Penalizing the 'hog' process by allowing it to run effectively
as a background MEMORY priority, might also be a solution, unless the hog has
realtime constraints of it's own.
(This is just meant as a data point for one aspect of the resource mgmt issue.)
John
- Next message: Michael Erskine: "Re: Linux as resilient as BSD, resource hogging?"
- Previous message: Stefan Kornexl: "Re: password policy"
- In reply to: Kasper Dupont: "Re: Linux as resilient as BSD, resource hogging?"
- Next in thread: Kasper Dupont: "Re: Linux as resilient as BSD, resource hogging?"
- Reply: Kasper Dupont: "Re: Linux as resilient as BSD, resource hogging?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
