Jan Dušátko wrote:
na tomto interface je poveseny stavovy packet filter, kde dovnitr je zakaz s
vyjimkou portu 22 a 80. Ven je povoleno vse.
V uvedene konfiguraci dokaze system obhodpodarit cca 2000-3000 klientu (cca
10000-15000 packet/sec)
Pokud spustim jeste fronty a nahodne rozdelovani (duvodem je vysoke
vytezovani linky nekterymi klienty), vykonnost system poklesne a dokaze
obhospodarit cca 1000-1500 klientu (cca 3000-5000 packet/sec)
Vtip nastane, pokud vypnu pf. V takovem okamziku se bavim o obsluze cca 20
000 klientu nez narazim na strop aplikace a zadne problem s timeouty.
Zatim mas problem porad jeste strasne siroky. Do hry nam vstupuje
"lagg", "stavovost", "modulate state", "altq" a nakonec cely "pf" framework.
Pokud nenajdes nekoho, kdo na stejny problem uz narazil a tudiz ma
analyzu provedenou a budes si ji muset delat sam, obavam se,z ew jedina
cesta bude pres izolaci problemu. To znamena zjistit jaky vliv ma na
chovani "stavovost", jestli se problem nahodou zazracne nevyresi
nahradou pf za ipfw, ...
Horsi je, ze nelze vyloucit, ze vysledny efekt spoluvytvari vic vlivu.
To, ze vypnuti "pf" prinese vyrazne zrychleni ale neni nijak prekvapive.
Ja sice PF nepouzivam, ale pokdu si to vybavuju dobre, tak interne je to
implementovano tak, ze pravidla, ktera ty pises, jsou v jadre ulozena ve
forme pseudokodu a u kazdeho pakety internpret bezici nad timto
pseudokodem rozhoduje "co dal". Pocet procesorovych instrukci, ktere
pruchod paketu vyzaduje, se tim zvysuje opravdu zasadne.
Mozna by mohl byt pekny a velmi uzitecny projekt vytvorit kompilator
pravidel do nativniho kodu procesoru - aby se obesla nutnost opakovane
interpretace mezikodu. A kdyby ten kompilator vytvarel kod
optimalizovany ...
Ale nepocitam s tim, ze byses do reseni problemu pustil tudy ;-)
Nakonec, nevime ani jak velky podil na problemu ma prave interpretace
pravidel.
Na takto vyznamne uzivane masine ti to ladeni rozhodne nezavidim, ale
nevidim jinou cestu jak se dobrat vysledku nez pokusovani s ruznymi
nastavenimi. Musel bysis vedle postavit testovaci stroj a dokazat proti
nemu vytvaret odpovidajici zatizeni - a to nevim, jestli mas takovou
moznost.
Dalsi zalezitosti je parovani sitovek pod vysokou zatezi. Z praxe vim, ze
parovani interface casto znamena vykon dolu, nekdy az na tretinu puvodniho
No, to je ztrata, ktera je tolerovatelna jen pokud ten vykon nepotrebujes.
V opacnem pripade je treba zvazit, zda jsou prostredky zvoleny dobre.
Zalezi proti vypadkum kterych komponent se presne jistis , ale mam za
dost dobre mozne, ze jak 'lagg' je mozna pro dany ucel zbytecne slozity
nastroj - a overhead souvisi prave s temi funkcemi, ktere mozna nakonec
vubec nepotrebujes ...
Pokud neni cilem zvyseni pruchodnosti (agregace) ale failover, pak bych
spis nez po lagg koukal pro bridge+stp. Tam bych cekal overhead mensi,
protoze v kazdy okamzik efektivne funguje jen jedna z obou karet coz
logiku zpracovani zjednodusuje a cekal bych overhead spis o dost mensi
nez 66% ...
Dan
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
