From: kuznet@ms2.inr.ac.ru
To: magnus.walldal@b-linc.com (Magnus Walldal)
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.1 under heavy network load - more info
Date: Wed, 21 Feb 2001 21:07:28 +0300 (MSK) [thread overview]
Message-ID: <200102211807.VAA16020@ms2.inr.ac.ru> (raw)
In-Reply-To: <HFEDLHHPHHEOBHLNPJOKAEIBCAAA.magnus.walldal@b-linc.com> from "Magnus Walldal" at Feb 21, 1 12:16:16 pm
Hello!
> OK! I actually expected 2.4 to be somewhat selftuning.
Defaults for these numbers (X,Y,Z) are very conservative.
> Interesting you say that, I looked at the logs and I see over 5000 sockets
> used, does'nt look peaceful to me. But you are absolutely right about the
> orphans. The error about "too many orphans" must be wrong and is triggered
> by some other condition. Look at the output from the debug printk I've
> added:
>
> Feb 18 15:43:50 mcquack kernel: TCP: too many of orphaned sockets
Well, message is not accurate. It refuses to hold this particular
orphan, because it feels that too much of memory is consumed.
Change number Z and the message will disappear.
Poor orphans are the first victims, because they have nobody
to take care of, but kernel. And kernel is harsh parent. 8)
> I raised the numbers a little bit more. Now with 128MB RAM in the box we can
> handle a maximum of 7000 connections. No more because we start to swap too
> much.
Really? Well, it is unlikely to have something with net.
Your dumps show that at 6000 connections networking eated less
than 10MB of memory. Probably, swapping is mistuned.
> Feb 21 10:43:41 mcquack kernel: KERNEL: assertion (tp->lost_out == 0) failed
> at tcp_input.c(1202):tcp_remove_reno_sacks
This is also debugging. Harmless.
> 2) The error about "too many orphans" is bogus?
Yes. It is sort of desinformation. It means really that
accounting detected excess of limits, which are set.
> 3) I will get a lot of debug crap i syslog
It will disappear as soon as debugging is disabled. I.e. when
kernel will enter distributions, I guess.
If I was responsible for this, I would not kill them.
The more messages is the better. Otherwise you would have
nothing to report and even did not notice that something is wrong. 8)
> This happened once under very heavy load (8000+ connections) and I have been
> unable to reproduce.
Probably this has nothing to do with tcp, but explained by some
vm failure, sort of oom killer.
Alexey
next prev parent reply other threads:[~2001-02-21 18:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <HFEDLHHPHHEOBHLNPJOKIEHNCAAA.magnus.walldal@b-linc.com>
2001-02-20 20:14 ` kuznet
2001-02-21 11:16 ` Magnus Walldal
2001-02-21 18:07 ` kuznet [this message]
2001-02-21 23:33 ` Rik van Riel
2001-02-23 12:51 ` Chris Evans
2001-02-23 13:38 ` Rik van Riel
2001-02-23 17:26 ` Magnus Walldal
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=200102211807.VAA16020@ms2.inr.ac.ru \
--to=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.walldal@b-linc.com \
/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
all inboxes | Powered by JetHome®