From: Simon Kirby <sim@netnation.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org
Subject: Re: Awfully slow /proc/net/tcp, netstat, in.identd in 2.4 (updated)
Date: Fri, 19 Oct 2001 08:59:44 -0700 [thread overview]
Message-ID: <20011019085944.A16467@netnation.com> (raw)
In-Reply-To: <20011018094222.A31919@netnation.com> <20011019145750.A22193@zero.firstfloor.org>
In-Reply-To: <20011019145750.A22193@zero.firstfloor.org>; from andi@firstfloor.org on Fri, Oct 19, 2001 at 02:57:50PM +0200
On Fri, Oct 19, 2001 at 02:57:50PM +0200, Andi Kleen wrote:
> On Thu, Oct 18, 2001 at 09:42:22AM -0700, Simon Kirby wrote:
> > There is definitely something really broken here. One of our web servers
> > that was having the problem before has now decided to hit a load average
> > of 50 because identd is taking so long to parse /proc/net/tcp and give
> > back ident information.
>
> See my last mail. The hash tables are too big. Set a smaller one
> during this patch by using the new tcpehashorder= command line option.
> It sets the hash table size as 2^order*4096 on i386. You can see the
> default order by looking at the dmesg of an machine booted without
> this option set.
> You can find out how much it costs you by looking at
> /proc/net/sockstat. If the tcp_ehash_buckets value is the same as
> with the default hash tab size then it didn't cost you anything.
> If the value is very similar it's probably still ok; just if you
> get e.g. average bucket length >5-10 it's probably too small.
> The smaller the hash table the faster should identd work.
Hmm, yeah, on this box with 640 MB I see:
TCP: Hash tables configured (established 262144 bind 65536)
(I'm guessing this means that the hash table has 32k buckets.)
Yes, that's fairly large, but not that huge for machines which will have
tons of sockets open.
Normally we use nothing like that:
sockets: used 133
TCP: inuse 118 orphan 3 tw 171 alloc 119 mem 132
RAW: inuse 0
FRAG: inuse 0 memory 0
...but shrinking the size slightly won't really fix the problem, it will
just make it less obvious.
Direct lookups for identd, service probes, etc., are definitely the
better way to go, but it would be nice if netstat didn't suck as well.
Simon-
[ Stormix Technologies Inc. ][ NetNation Communications Inc. ]
[ sim@stormix.com ][ sim@netnation.com ]
[ Opinions expressed are not necessarily those of my employers. ]
next prev parent reply other threads:[~2001-10-19 16:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-18 16:42 Awfully slow /proc/net/tcp, netstat, in.identd in 2.4 (updated) Simon Kirby
2001-10-18 16:49 ` David S. Miller
2001-10-18 17:05 ` Simon Kirby
2001-10-19 12:57 ` Andi Kleen
2001-10-19 15:59 ` Simon Kirby [this message]
2001-10-19 18:22 ` Andi Kleen
2001-10-19 20:59 ` David S. Miller
2001-10-19 21:30 ` Benjamin LaHaise
2001-10-19 21:56 ` David S. Miller
2001-10-19 22:04 ` Benjamin LaHaise
2001-10-19 22:11 ` David S. Miller
2001-10-19 22:13 ` Benjamin LaHaise
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=20011019085944.A16467@netnation.com \
--to=sim@netnation.com \
--cc=andi@firstfloor.org \
--cc=kuznet@ms2.inr.ac.ru \
--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