On Sat, 27 May 2000, Catherine Sullivan wrote:
>
> This was , umm, I don't know, about an hour later - tombstones on the
> perf and no prompt on the channel. What does this mean? Is this enough
> time?
> :-)
> Cat
If you have tombstones on the perfmeter, that's bad. It means that at
least rpc.rstatd isn't responding, probably because inetd has been killed by
Linux and isn't launching it. And probably means it needed to be booted.
One thing that can happen, when one server goes down, requests for files
from that server by another will back up and can exhaust all memory. I have
the maximum number of client processes set low enough that it really shouldn't
but it seems to anyway.
Linux handles out of memory situation in a piss poor manner, randomly
killing what it thinks are memory hogs rather than just refusing memory
requests or forks of additional processes. Giving it lots of swap doesn't seem
to help.
It also seems to act badly when memory is too fragmented rather than
simply using swap to defragment it like SunOS does. Why the memory management
is still so crude for an OS that has been around as long as Linux has is beyond
me. If you don't have enough memory on a SunOS box, like eskimo, it just gets
slow instead of exploding.
The thing that is strange, the really antique Linux kernel didn't seem to
exhibit this behavior. Out of curiosity and bordem, while I was at US West, we
setup a 386 box with a whole of 4MB of RAM, with I think it was .98 Linux,
X-windows, and open windows window manager. The hard drive light was more or
less continuously on, but it didn't do anything weird like randomly kill
processes and it wasn't noticably slower than an IPX with 16MB.
I'd like to know if 2.4 is going to be at all improved in this regards, I
have read about plans to have it exclude processes with a PID below a certain
number which would protect system daemons provided they aren't restarted, but
I'd really like to have the option of not having it kill running processes at
all.
-
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/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:18 EST