From: Christian Schmid <webmaster@rapidforum.com>
To: "David S. Miller" <davem@davemloft.net>
Cc: Stephen Hemminger <shemminger@osdl.org>, netdev@oss.sgi.com
Subject: Re: Bug in 2.6.10
Date: Fri, 28 Jan 2005 21:03:39 +0100 [thread overview]
Message-ID: <41FA9A9B.2000601@rapidforum.com> (raw)
In-Reply-To: <20050128114600.46f3a70a.davem@davemloft.net>
>>>Hello.
>>>
>>>In 2.6.10 there has been a "bug" introduced. You may also call it a feature, but its a crappy
>>>feature for big servers. It seems the kernel is dynamically adjusting the buffer-space available for
>>>sockets. Even if send-buffer has been set to 1024 KB, the kernel blocks at less if there are enough
>>>sockets in use. If you have 10 sockets with 1024 KB each, they do not block at all, using full 1024
>>>KB. If you have 4000 sockets, they only use 200 KB. So it seems its blocking at 800 MB. This is
>>>good, if you have a 1/3 system, because else the kernel would run out of low mem. But I have a 2/2
>>>system and I need them for buffers. So what can I do? Where can I adjust the "pool"?
>>
>>You can set the upper bound by setting tcp_wmem. There are three values
>>all documented in Documentation/networking/ip-sysctl.txt
>
>
> This feature is meant also to prevent remote denial of service
> attacks. It limits the amount of system memory TCP can
> consume on your system.
>
> Before this feature went in, it's really easy to remotely make a system
> consume %90 of system memory just with socket buffers.
Thank you for your reply.
Yes this is possible for most situations. Isn't there a way to disable it or at least adjust the
level? As said, I have a 2/2 system and I would like to set it to 1500 MB. this is important for my
big server.
Oh and for that DOS-thingy, my two cents: It would be better if buffer-sockets are dynamically
adjusted. So that memory is only allocated if the queue is really needed. Most of the allocated
memory is mostly unused because queues are mostly empty.
Please help me.
Thank you in advance,
Chris
next prev parent reply other threads:[~2005-01-28 20:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-28 19:27 Bug in 2.6.10 Christian Schmid
2005-01-28 19:42 ` Stephen Hemminger
2005-01-28 19:46 ` David S. Miller
2005-01-28 20:03 ` Christian Schmid [this message]
2005-01-28 20:04 ` Ben Greear
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=41FA9A9B.2000601@rapidforum.com \
--to=webmaster@rapidforum.com \
--cc=davem@davemloft.net \
--cc=netdev@oss.sgi.com \
--cc=shemminger@osdl.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).