>>> Just a thought, but how much memory does root need to do suchlike
>>> cleanups? Let's see - load the login shell (probably already in
>>> memory anyway, so 0k), run ps (may already be in memory) to find
>>> out which processes are currently hogging memory, then kill
>>> (usually a shell internal, so 0k) to get rid of a few of
>>> them...that should do...
>> You are not counting the individual data segments of every bash
>> etc...
> It seems I need to explain the trouble I experienced (this is how
> one of my colleagues explained it to me ... )
> Picture this. We're running some Cobol (*sigh*) applications which,
> based on the sale of my employer, calculates totals, income,
> handling stock and so on. These applications are handling some
> rather large databases (1.4Gig and up). The cobol runtime /
> applications does as much of their work in ram as possible. So as
> long as it get the ram, it uses it. And Linux is giving away the
> ram as fast as possible ;o)
> The cobol-runtime has this bad habit of 'hanging' when it can't get
> more free ram (memory exhausted). It's not Liunx'es fault. It's the
> runtime vendor - they admit it. "But wait until version 4.2, it will
> be out in 1999 ..." We can't live with that.
> Oh! The cobol-applications are usually run during night when nobody
> uses the servers - so no 'bash', 'ps' or the like are in the cache.
> The next morning when somebody tries to login (s)he will be denied
> access ....
> And to make matters even worse. It's not *everyday* we experience this
> - it's dependable on how well my employer is selling ... (lot of sale
> means lot of data to be handled ...)
I can understand the problem there, but surely a better solution would
be to have a limit such that no one process may use more than (say)
90% of non-kernel system memory, thus ensuring that there's always
some memory free, and have that limit tweakable...
Also, just a thought, but would more swap space help?
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/