Hi Jeremie Le Hen!
On Mon, 8 Oct 2012 12:49:34 +0200; Jeremie Le Hen wrote about 'Re: sysctl
kern.ipc.somaxconn limit 65535 why?':
On 03.10.2012 22:03, Adrian Chadd wrote:
somaxconn is the connection queue depth. If it's sitting at a couple
hundred thousand then something else is going
.. let's like, create some better sysctl descriptions? :-)
Then encourage those to be used in documentation somewhere?
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send
Hi,
On Wed, Oct 03, 2012 at 10:15:32PM +0200, Andre Oppermann wrote:
On 03.10.2012 22:03, Adrian Chadd wrote:
somaxconn is the connection queue depth. If it's sitting at a couple
hundred thousand then something else is going crazily wrong.
I understand your frustration, but there's a
On 03/10/2012 22:15, Andre Oppermann wrote:
I guess the problem is rather kern.ipc.maxsockets which is only 25600.
maxsockets should be bumped up quite a bit by default IMO. How far needs
some analysis because there are some dependencies and memory
requirements.
So, how about a heuristic,
On 5 October 2012 05:26, Ivan Voras ivo...@freebsd.org wrote:
On 03/10/2012 22:15, Andre Oppermann wrote:
I guess the problem is rather kern.ipc.maxsockets which is only 25600.
maxsockets should be bumped up quite a bit by default IMO. How far needs
some analysis because there are some
On Fri, Oct 05, 2012 at 08:21:53AM +1000, Peter Jeremy wrote:
On 2012-Oct-03 19:45:01 +0100, free...@chrysalisnet.org wrote:
In addition we had to migrate all our mysql servers from freebsd to debian
because they were hitting some arbitary OS limit but I could never figure
out what, sys% usage
On 2012-Oct-03 19:45:01 +0100, free...@chrysalisnet.org wrote:
In addition we had to migrate all our mysql servers from freebsd to debian
because they were hitting some arbitary OS limit but I could never figure
out what, sys% usage went through the roof when this limit was hit, issue
didnt occur
On 4 October 2012 15:21, Peter Jeremy pe...@rulingia.com wrote:
On 2012-Oct-03 19:45:01 +0100, free...@chrysalisnet.org wrote:
In addition we had to migrate all our mysql servers from freebsd to debian
because they were hitting some arbitary OS limit but I could never figure
out what, sys% usage
Hi everyone.
Actually 65k sockets is incredibly easy to reach.
I manage some servers for a very large website, it currently has several
http servers clustered to handle daily traffic and this is only dynamic
content, static has its own servers, databases also have own servers.
We recently
On Wed, Oct 3, 2012 at 11:45 AM, free...@chrysalisnet.org wrote:
Hi everyone.
Actually 65k sockets is incredibly easy to reach.
I manage some servers for a very large website, it currently has several
http servers clustered to handle daily traffic and this is only dynamic
content, static
Hi,
somaxconn is the connection queue depth. If it's sitting at a couple
hundred thousand then something else is going crazily wrong.
I understand your frustration, but there's a lot of instances where
the application just isn't doing things right and the OS tries to
hide it as much as psosible.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
On 10/03/12 11:45, free...@chrysalisnet.org wrote:
Hi everyone.
Actually 65k sockets is incredibly easy to reach.
No, this is not kern.ipc.maxsockets.
kern.ipc.somaxconn is for baclkog and not the maximum connections.
Accumulating 64K of
On 3 October 2012 13:01, Garrett Cooper yaneg...@gmail.com wrote:
Here's where it's being held at 65535 (sys/kern/kern_uipc.c):
3276 static int
3277 sysctl_somaxconn(SYSCTL_HANDLER_ARGS)
3278 {
3279 int error;
3280 int val;
3281
3282 val = somaxconn;
3283
On 03.10.2012 22:03, Adrian Chadd wrote:
Hi,
somaxconn is the connection queue depth. If it's sitting at a couple
hundred thousand then something else is going crazily wrong.
I understand your frustration, but there's a lot of instances where
the application just isn't doing things right and
On Wed, Oct 3, 2012 at 1:03 PM, Adrian Chadd adr...@freebsd.org wrote:
Hi,
somaxconn is the connection queue depth. If it's sitting at a couple
hundred thousand then something else is going crazily wrong.
I understand your frustration, but there's a lot of instances where
the application
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/03/12 13:47, Garrett Cooper wrote:
On Wed, Oct 3, 2012 at 1:03 PM, Adrian Chadd adr...@freebsd.org
wrote:
Hi,
somaxconn is the connection queue depth. If it's sitting at a
couple hundred thousand then something else is going crazily
Or the TTL of TCP connections might be too high for the volume of
connections received. Someone else on net@ reported that changing
this value to more aggressively reap sockets improved performance
greatly (at the cost that more connections potentially needing to
be reestablished and/or
On Wed, Oct 3, 2012 at 3:03 PM, Ryan Stone ryst...@gmail.com wrote:
Or the TTL of TCP connections might be too high for the volume of
connections received. Someone else on net@ reported that changing
this value to more aggressively reap sockets improved performance
greatly (at the cost that
sunsaturn:~# sysctl -w kern.ipc.somaxconn=20
kern.ipc.somaxconn: 4096
sysctl: kern.ipc.somaxconn: Invalid argument
sunsaturn:~# sysctl -w kern.ipc.somaxconn=65536
kern.ipc.somaxconn: 4096
sysctl: kern.ipc.somaxconn: Invalid argument
sunsaturn:~# sysctl -w kern.ipc.somaxconn=65535
On Wed, 4 Jan 2012, Chuck Swiger wrote:
On Jan 4, 2012, at 12:22 PM, Dan The Man wrote:
Trying to stress test a framework here that tosses 100k of connections into a
listen queue before doing anything, I realize I'll have to use multiple local
IPs get get around port limitations, but why is
On Jan 4, 2012, at 12:44 PM, Dan The Man wrote:
Even a backlog of a 1000 is large compared to the default listen queue size
of around 50 or 128. And if you can drain 1000 connections per second, a
65K backlog is big enough that plenty of clients (I'm thinking web-browsers
here in
On Wed, 4 Jan 2012, Chuck Swiger wrote:
On Jan 4, 2012, at 12:44 PM, Dan The Man wrote:
Even a backlog of a 1000 is large compared to the default listen queue size of
around 50 or 128. And if you can drain 1000 connections per second, a 65K
backlog is big enough that plenty of clients (I'm
On Wed, 4 Jan 2012, Dan The Man wrote:
On Wed, 4 Jan 2012, Chuck Swiger wrote:
On Jan 4, 2012, at 12:44 PM, Dan The Man wrote:
Even a backlog of a 1000 is large compared to the default listen queue
size of around 50 or 128. And if you can drain 1000 connections per
second, a 65K backlog
On Jan 4, 2012, at 12:22 PM, Dan The Man wrote:
Trying to stress test a framework here that tosses 100k of connections into a
listen queue before doing anything, I realize I'll have to use multiple local
IPs get get around port limitations, but why is this backlog using a limit?
Even a
On Jan 4, 2012, at 1:03 PM, Dan The Man wrote:
However, I'm not convinced that it is useful to do this. At some point, you
are better off timing out and retrying via exponential backoff than you are
queuing hundreds of thousands of connections in the hopes that they will
eventually be
Hi,
On Wed, Jan 4, 2012 at 4:42 PM, Chuck Swiger cswi...@mac.com wrote:
On Jan 4, 2012, at 1:03 PM, Dan The Man wrote:
However, I'm not convinced that it is useful to do this. At some point,
you are better off timing out and retrying via exponential backoff than you
are queuing hundreds of
On Jan 4, 2012, at 1:49 PM, Arnaud Lacombe wrote:
Hi,
On Wed, Jan 4, 2012 at 4:42 PM, Chuck Swiger cswi...@mac.com wrote:
On Jan 4, 2012, at 1:03 PM, Dan The Man wrote:
However, I'm not convinced that it is useful to do this. At some point,
you are better off timing out and retrying via
On Wed, 4 Jan 2012, Chuck Swiger wrote:
On Jan 4, 2012, at 1:49 PM, Arnaud Lacombe wrote:
Hi,
On Wed, Jan 4, 2012 at 4:42 PM, Chuck Swiger cswi...@mac.com wrote:
On Jan 4, 2012, at 1:03 PM, Dan The Man wrote:
However, I'm not convinced that it is useful to do this. At some point, you
are
Hi,
On Wed, Jan 4, 2012 at 3:22 PM, Dan The Man d...@sunsaturn.com wrote:
sunsaturn:~# sysctl -w kern.ipc.somaxconn=20
kern.ipc.somaxconn: 4096
sysctl: kern.ipc.somaxconn: Invalid argument
sunsaturn:~# sysctl -w kern.ipc.somaxconn=65536
kern.ipc.somaxconn: 4096
sysctl:
On Wed, 4 Jan 2012, Dan The Man wrote:
On Wed, 4 Jan 2012, Chuck Swiger wrote:
On Jan 4, 2012, at 1:49 PM, Arnaud Lacombe wrote:
Hi,
On Wed, Jan 4, 2012 at 4:42 PM, Chuck Swiger cswi...@mac.com wrote:
On Jan 4, 2012, at 1:03 PM, Dan The Man wrote:
However, I'm not convinced that it is
Hi,
On Wed, Jan 4, 2012 at 2:50 PM, Dan The Man d...@sunsaturn.com wrote:
[...]
How about a sensible solution? I think everyone has been making valid points
here, about sensible limits for all programs on system and per application
limit changes.
How about changing the hard limit high, and
Hi--
On Jan 4, 2012, at 2:23 PM, Dan The Man wrote:
It is not arbitrary. Systems ought to provide sensible limits, which can be
adjusted if needed and appropriate. The fact that a system might have
50,000 file descriptors globally available does not mean that it would be OK
for any
On Wed, 4 Jan 2012, Chuck Swiger wrote:
Hi--
On Jan 4, 2012, at 2:23 PM, Dan The Man wrote:
It is not arbitrary. Systems ought to provide sensible limits, which can be adjusted if
needed and appropriate. The fact that a system might have 50,000 file descriptors
globally available does
On Jan 4, 2012, at 4:09 PM, Dan The Man wrote:
With the new IBM developments underway of 16 core atom processors and
hundreds of gigabytes of memory, surely a backlog of 100k is manageable. Or
what about the future of 500 core systems with a terrabyte of memory, 100k
listen queue could be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/04/12 16:09, Dan The Man wrote:
On Wed, 4 Jan 2012, Chuck Swiger wrote:
Hi--
On Jan 4, 2012, at 2:23 PM, Dan The Man wrote:
It is not arbitrary. Systems ought to provide sensible
limits, which can be adjusted if needed and
Hi, Xin--
On Jan 4, 2012, at 5:32 PM, Xin Li wrote:
I am personally quite convinced that FreeBSD should make such change
though -- having more than 64K of outstanding and unhandled
connections does not sound a great idea (i.e. it's not a connection
limit after all, but the pending handle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/04/12 17:49, Chuck Swiger wrote:
Hi, Xin--
On Jan 4, 2012, at 5:32 PM, Xin Li wrote:
I am personally quite convinced that FreeBSD should make such
change though -- having more than 64K of outstanding and
unhandled connections does not
37 matches
Mail list logo
