FreeBSD: 1.6+ millió egyidejű kapcsolat

Címkék

Sokan állítják, hogy a FreeBSD TCP/IP stackje a legjobb a világon. Azt, hogy az egyik legstabilabb OS, azt mi sem bizonyítja jobban mint, az hogy a Netcraft-on a "longest uptime" kategóriában az első 10 gép közül 7 FreeBSD ( a többi három BSD/OS néven fut), az első helyezett FreeBSD 1399 napos uptime-mal vezet. Az első 50-ben szinte csak BSD-k vannak, néhány Irix, Solaris, három Win2K! viszont egy darab Linux box sem található itt. Az uptime nem minden! mondják sokan, és igazuk van. Viszont itt egy újabb FreeBSD rekord:

Terry Lambert postázott egy érdekes levelet a @freebsd-hackers listára, amelyben azt állítja, hogy több, mint 1.6 millió egyidejű kapcsolatot tud kiszolgálni egy FreeBSD 4.4 box. A bejelentésben egy általa tuningolt FreeBSD-ről beszél, amelyen Ő mérte a fent említett eredményt. A gép 1,603,127 egyidejű kapcsolatot szolgált ki 4GB fizikai memóriával, IPSEC használata nélkül. Ha a mérés hiteles, akkor úgy tűnik, hogy ez egy rekord az x86 kategóriában.

Bejelentés:Date: Sun, 26 Jan 2003 17:36:30 -0800

From: Terry Lambert

To: Sam Tannous

Cc: freebsd-hackers@freebsd.org

Subject: Re: max simultaneous TCP connections

(32,763)?

Sam Tannous wrote:

> I have two freebsd boxes (back to back) and I've

> been playing with a simple server on one machine

> and client on the other machine (this was simply

> an exercise with playing with kqueue). Both the

> server and the client are single processes and the

> client seems to stop at 32,763 connections.

>

> I've modified the port range, tcp keepalive,

> kern.ipc.somaxconn, maxfiles, maxsockets, nmbclusters.

> I even tried net.inet.tcp.tcbhashsize (up to 1024).

>

> Is there some other parameter I'm missing? Or is this

> a known limitation/bug?

You must tune up maxfiles at boot time, not afterwards, or

the number of tcpcb's and inpcb's will be limited to the

value of maxfiles at compile time, no matter what you set

it to later with that !#$%@&*! sysctl that pretends to be

read/write, but should really be read-only after boot time.

The limit on outbound connections is 65535. Technically,

this is per IP, but you will have to read the kernel code

in some detail to use more than one IP, since FreeBSD has a

bug in inpcballoc, in that it treats all outbound sockets as

if they are allocated from the INADDR_ANY range, even if you

are only using a single IP address (technically, you should

be able to bind on the way out before a connect, but there

are some hoops ou have to jup through to avoid certain "if"

tests that should not be there.

Given the 32763 number, it looks like you are just quoting me

back to me, pretending the historical answer is the current

answer, and that has not been accurate since FreeBSD 4.5.

I have *personally* tuned a FreeBSD box with 4G of RAM, and

*personally* achieved a reacord number of connections.

The current record is 1,603,127 simultaneous connections, in

FreeBSD 4.4, without IPSEC.

As far as I know, I hold the single machine connection record

for an x86 box.

-- Terry

Hozzászólások

Ez nagyon szép, de ki is lehet használni? :) Úgy értem, hogy nem csak kapcsolatokat hoz létre, hanem csinál is velük valami értelmeset.

Az uptime témát már jópárszor kitárgyalták a FreeBSD listákon, érdemes elolvasni azokat a leveleket.

Terry Lambert leveleiről meg csak annyit, hogy mindet érdemes elolvasni, nagyon tartalmasak és érdekesek. Egy dolgot nem értek csupán: ha ennyire érti a dolgát, miért nem foltozza be a lyukakat ő maga?

Szép lassan forgalmaz rajta. 4 (3-3,5GB?) kernel memóriával nem igazán lehet túl magas a kapcsolatokra fenntartott puffer mérete, illetve ha jobban utánaszámolunk, még egy 10 Gbps-es interfészen is (amit egy PC nyilván nem tud kiszolgálni) kb. 6 kBps-t jelent ennyi kapcsolat.

Feltéve persze, hogy mindegyiken történik is valami, illetve ideális minden :)

Pár szimpla PC... Ma már nem olyan nagy szám egy PC szerverből kihúzni 5-600 Mbps-t. Ha ezt szorzod 10-20-szal már ott is vagy...

Hi,

ezt lattatok?:

http://uptime.netcraft.com/up/accuracy.html#whichos

Nem ertem, az uptime-ot nem tamogato rendszerek kozul Compaq True 64-en es OpenBSD-n (3.2) kiprobaltam, mindketton volt uptime...

Mas:

viszont egy darab Linux box sem található itt.

Van egy Linuxom, ami 497+130 napja fut, ez azert mar osszemerheto az emlegetett ertekekkel. Hogy ki jelentkezik a felmeresre, es ki nem az az o dolga.

Es meg mas: ennek ellentmond a szereny magan velemenyem: a 100 nap feletti uptime minositi a rendszergazdat... :)

>Nem ertem, az uptime-ot nem tamogato rendszerek kozul Compaq True 64-en es OpenBSD-n (3.2) kiprobaltam, mindketton volt uptime...

En ugy tudom, hogy uptime van rajta, csak a NetCraft nem tudja tavolrol monitorozni

>Van egy Linuxom, ami 497+130 napja fut,

Hat ha osszeadom: 497+130=627, ez marha messze van az 1399-tol ;-)

>ennek ellentmond a szereny magan velemenyem: a 100 nap feletti uptime minositi a rendszergazdat... :)

hehe ;-)

Hello,

Hat ha osszeadom: 497+130=627, ez marha messze van az 1399-tol ;-)

En a top50-el merem ossze, nem a top10-el. Igy kezded a mondatod:

Az első 50-ben szinte csak BSD-k vannak,...

Na erre irtam a "Linuxomat". :)

Amugy tegnaphoz kepest nagyon megvaltozott a lap, hirtelen elokerultek 1500++ napos rendszerek is. Az 1399 mar csak a 4. helyezett.

Kb. annyi haszna van ennek az uptime meresnek, mint az 1.6 mill egyideju kapcsolatnak. :)

air

Miert a palacsinta evessel beallitott Guinnes rekordnak mi ertelme van? Vannak olyan dolgok aminek az eg vilagon semmi ertelmuk sincs, de megis szamontartjuk oket. Es a Netcraft milyen jol meg is el belole ;-)

>,mint az 1.6 mill egyideju kapcsolatnak. :)

Szerintem van haszna annak, ha valaki egy architektura teljesitokepessegenek hatarait keresi. Igy szoktak a "hihetetlen, de igaz" projectek indulni. Ugy, hogy valaki mindig elegedetlen a jelenlegivel....

IPSecről, vagy SSL-ről eredetileg szó sem volt, de korántsem tartom kizártnak, hogy a leggyorsabb AMD Athlon XP (vagy ebből kettő megfelelő szoftveres implementáció esetén), vagy Xeon képes legyen ilyen teljesítményre. Főleg ha nem 3DES-ről, hanem mondjuk AES-ről van szó IPSec esetén...

Azt pedig sehol sem vontam kétségbe, hogy a célhardverből sokkal többet lehet kihozni, mint egy általános célra készült gépből. De ugyanez igaz a rajtuk futó szoftverre is...