From: "Lauro, John" <jlauro@umflint.edu>
To: <linux-kernel@vger.kernel.org>
Subject: Stalls from low free memory on 2.4.18 too
Date: Tue, 3 Jun 2003 15:51:19 -0400 [thread overview]
Message-ID: <37885B2630DF0C4CA95EFB47B30985FB020EC020@exchange-1.umflint.edu> (raw)
Hello,
I did some more tests from a 12GB server that I am trying to make
stable under heavy writes...
I tried a few different patches, but nothing helped so far.
I also tried going down to 2.4.18. At first, it appeared to be
working, but... it just took a little longer to fail... 2.4.18 seems
slower on disk I/O. It's giving me about a 30% reduction in BI or
BO/sec, but could be caused from other factors. With 2.4.18 I was
sustaining about 20000 BO/sec compared to over 30000 with 2.4.20
(according to vmstat 1). However, free memory was rarely going below
5000, and with 2.4.20 it seemed to dip below 4000 sooner. Then, with
2.4.18 after some time it too decided to get stuck under 4000 free and
after several seconds of vmstat 1 reporting free under 3900 it stop
reponing. Walking over to the server room, <shift><scroll> shows free
staying around 780-805 (waiting about 30 seconds between tries).
Tried killing the connections, etc... and finally gave up and
rebooted.
How can Linux seem to allocate memory for running a program that
malloc() a bunch of memory and then exits (freeing a bunch of pages
for the kernel) work so quickly, but.... consume memory quicker then
it can free it for write operations?
Is it possible that once memory gets too tight, that either:
1. Calls to actually empty buffers and get info on disk are being
blocked somewhere
2. The routine that frees memory doesn't have enough memory to
run
3. or some other subsystem is deadlocking because free memory is
too low and it's failing to allocate, and eating up all the CPU so
everything else stalls
Would it be possible to somehow throttle write requests halfway
between the freepages min and freepages low??? Is it possible to even
set those values (modify the source?), as they are still documented,
but are not in /proc???
One item I have not tried yet is one of the alternate memory
allocation patches that are supposed to work better with HIGHMEM.
reply other threads:[~2003-06-03 19:40 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=37885B2630DF0C4CA95EFB47B30985FB020EC020@exchange-1.umflint.edu \
--to=jlauro@umflint.edu \
--cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).