> Date: Sun, 4 Dec 2011 15:10:56 +0100 > From: Claudio Jeker <cje...@diehard.n-r-g.com> > > On Sun, Dec 04, 2011 at 01:35:33PM +0100, Sebastian Reitenbach wrote: > > On Sunday, December 4, 2011 13:24 CET, Camiel Dobbelaar <c...@sentia.nl> > > wrote: > > > > > On 4-12-2011 13:01, Sebastian Reitenbach wrote: > > > > the default maximum size of the tcp send and receive buffer used by the > > > > autosizing algorithm is way too small, when trying to get maximum speed > > > > with high bandwidth and high latency connections. > > > > > > I have tweaked SB_MAX on a system too, but it was for UDP. > > > > > > When running a busy Unbound resolver, the recommendation is too bump the > > > receive buffer to 4M or even 8M. See > > > http://unbound.net/documentation/howto_optimise.html > > > > > > Otherwise a lot of queries are dropped when the cache is cold. > > > > > > I don't think there's a magic value that's right for everyone, so a > > > sysctl would be nice. Maybe separate ones for tcp and udp. > > > > > > I know similar sysctl's have been removed recently, and that they are > > > sometimes abused, but I'd say we have two valid use cases now. > > > > > > So I'd love some more discussion. :-) > > > > since they were removed, and there is this keep it simple, and too many > > knobs are bad attitude, which I think is not too bad, I just bumped the > > SB_MAX value. > > If there is consensus that a sysctl would make sense, I'd also look into > > that approach and send new patch. > > SB_MAX is there to protect your system. It gives a upperbound on how much > memory a socket may allocate. The current value is a compromize. Running > with a huge SB_MAX may make one connection faster but it will cause > resource starvation issues on busy systems. > Sure you can bump it but be aware of the consequneces (and it is why I > think we should not bump it at the moment). A proper change needs to > include some sort of resource management that ensures that we do not run > the kernel out of memory.
But 256k simply isn't enough for some use cases. Turning this into a sysctl tunable like FreeBSD and NetBSD would be a good idea if you ask me. Yes, people will use it to shoot themselves in the foot. I don't care.
