From: Lonnie Nunweiler <lonnie@valemount.com>
To: linux-mm@kvack.org
Subject: memory use in Linux
Date: Thu, 20 Aug 1998 22:37:33 -0700 [thread overview]
Message-ID: <3.0.3.32.19980820223733.006b4b5c@valemount.com> (raw)
I am researching why Linux runs into memory problems. We recently had to
convert our dialin server, email and web server to NT, because the Linux
machine would eventually eat up all ram, and then crash. We were using
128MB machines, and it would take about 3 days before rebooting was
required. If we didn't reboot soon enough, it was a very messy job
rebuilding some of the chewed files.
I have encountered the saying "free memory is wasted memory", and it got me
thinking. I believe that statement is completely wrong, and is responsible
for the current problems that Linux is having for systems that keep running
(servers) as opposed to systems that get shut down nightly.
If we were to treat memory as money, we would not think that money sitting
idly in the bank is wasted. I've been there, with no reserves, and it is
not fun. If too much is sitting idle, it might not be best, but let it
sit. It is ready in an instant should we need it. If it is not there when
we need it, we scramble, and sometimes get embarrassed.
I think the memory manager should place limits on caching, so as to leave a
specified amount of free ram.
>From what I have observed, processes will eventually use up all available
ram, and get into swapping. Imagine having a buddy or partner that was
just following you around to get any money you earned, and immediately
spent it. Eventually important things would be delayed until you could get
enough put aside to cover them.....only problem, that buddy is grabbing
anything you put away, and spending it. You try as hard as you wish, but,
no way can you get ahead. Then total disaster strikes. Your partner has
gotten hold of a credit card. At this point you can forget about ever
having anything to spare. Time to reboot.
It's silly to have a 64M machine, running only a primary DNS task, and
having it slowly get its memory chewed up, and then get into swapping.
When it crashes due to no available memory, what was gained in a few
milliseconds faster disk access because of caching?
Is it possible to configure Linux to limit the performance speeder-uppers
to leave a specified chunk of ram available? Do you think this would help
with reliability? Can anyone tell me how to do it?
Thanks
Lonnie Nunweiler, President
WebWorld Warehouse Ltd.
1255 - 5 th Ave.
PO Box 1030
Valemount, BC. V0E 2Z0
www.valemount.com
www.webworldwarehouse.com
lonnie@valemount.com
lonnie@vis.bc.ca
Voice: (250) 566-4698 Fax: (250) 566-9835
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
next reply other threads:[~1998-08-21 5:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-08-21 5:37 Lonnie Nunweiler [this message]
1998-08-21 6:20 ` Adam Fritzler
1998-08-21 23:48 ` Eric W. Biederman
1998-08-24 10:36 ` Stephen C. Tweedie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3.0.3.32.19980820223733.006b4b5c@valemount.com \
--to=lonnie@valemount.com \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox