Hello. We have a webserver using FreeBSD, we read about tunning kern.ipc.somaxconn (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html) so the OS can handle all the connections. Is there a way to know how many connections are established in a certain moment?. I know about netstat(1) but is there any other command that we can use to know the exact amount of how many connections are established?. Thanks in advance.
On Tue, Jan 29, 2013 at 7:26 PM, Efra?n D?ctor <efraindector at motumweb.com>wrote:> Hello. > > We have a webserver using FreeBSD, we read about tunning > kern.ipc.somaxconn ( > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html) > so the OS can handle all the connections. Is there a way to know how many > connections are established in a certain moment?. I know about netstat(1) > but is there any other command that we can use to know the exact amount of > how many connections are established?. >sockstat(1) There are other sysctl's to view connections in a particular state such as net.inet.tcp.pcblist: -- Adam Vande More
On 30/01/2013 12:26 PM, Efra?n D?ctor wrote:> Hello. > > We have a webserver using FreeBSD, we read about tunning kern.ipc.somaxconn (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html) so the OS can handle all the connections. Is there a way to know how many connections are established in a certain moment?. I know about netstat(1) but is there any other command that we can use to know the exact amount of how many connections are established?. > > > Thanks in advance. > _______________________________________________ > freebsd-stable at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" >This one might help: kern.ipc.numopensockets: Number of open sockets It's usefulness will depend on the granularity you require (in only, out only, established only, etc) but it's always represented system-wide resource consumption very well (matching observed workloads - <some baseline value>) -- Ta, Koobs