Chci opět rozvířit diskusi nad výkoností HTB, resp. stroje na kterém to musí běžet.
Problém: při 100Mbit lince je prakticky nemožné rozumně QOSovat. Stroj Core2Duo 2.13GHz, síťovky e1000 (jedna na PCIe, druhá na normál PCI). Expressovka je do gigového switche, druhá do 100M rozhraní ceragonu. Vytížení obou procesorů je přibližně 50% každý, ve špičkách (při průtoku cca 80M a 10k paketů/s každým směrem) až okolo 90%. Vše zabírá "kernelový" čas.
Řešení: pomocí promethea0.7a řízení provozu každé IP extra. Je to tak, že každý uživatel má svoji třídu do které mu "padají" všechny jeho IP adresy. Takže kapacita je rozdělená poctivě na cca 1500 kousíčků s minimem (rate) 66kbit a různým maximem (ceil) dle kvality jeho umístění na síti. Není to úplně přesný popis, některé classy mají rate jiný (servery, voip zařízení, apod.), ale pro seznámení stačí.
Strom classes je 4 úrovňový: interface->wan->skupiny->uživatelé. Tak jak to vytváří prometheus.
Na tom samém počítači je jak QOS (tedy HTB&SFQ) ale i SNAT&DNAT. Iptables pravidla (markovací a natkovací) výkon nijak neovlivňují. Jejich zrušení prostě nic nedělá (resp. se to nedá změřit). Ovšem zrušení veškerých qos class ano, vytížení klesne na nějakých 3-4%
Tak a co teď? Podělíte se s vlastními zkušenostmi, jak to děláte u vás a co to stojí (výkonu)?
Snažím se vytvořit nějakou teorii, která by mi pomohla. Ale nějak se mi moc nedaří a ještě hůř se to zkouší ...
a) předělat QOSení na u32 filter dle IP. Může někdo potvrdit nárůst výkonu oproti filtru na MARK?
b) posílit CPU na serveru. Lze jít (a to zatím nevím jestli to snese MB) až někam k 3GHz. Bohužel neumím odhadnout, kolik procent to přinese ... silně pochybuju, že 40% zlepšení ... (pěti deseti se nemá cenu asi zabývat). Stejně tak jsem skeptický ke zvyšování počtu jader.
c) IO výkon síťovek. Vyhodit (resp nepoužívat) stávající a použít něco lepšího, serverově zaměřeného? Prostě dvouportovou, gigabitovou do PCIe?
d) snažím se pochopit NAPI POLLING. Vzhledem k počtu IRQ na tomto stroji to zjevně nepoužívám. Máte to někdo takto funkční? Můžu čekat velké zlepšení?
e) změna časovače v jádře - parametr CONFIG_HZ. Ale kam? Dolů nebo nahoru? Logicky si odvozuji, že v tomto případě spíš nahoru ... ať to ty paketíky rychleji přehazuje. Ale mohu se mýlit ...
f) preemption model - pomůže něčemu "No forced (server)"?
g) koupit něco jako Paketeer. Bohužel ale nekradu ...
Filtry mame pres U32. Masina, ktera dela NAT + shaper do internetu (+ devka na dalsi veci) je dvouprocesorova PIII/1G. Sitovky klasicke e100 (dve onboard + jedna dvouport v 32bit PCI; irq jsou momentalne rozbalancovane mezi obe cpu). Spickove tam tece ~15-20M a kope se to nudou do ****, nejvic zateze mi tam ted dela generovani nejakych grafu kolem.
Mozna je to tim, ze tech trid/filtru na pruchod tam je taky podstatne min (neco pres stovku; teoreticky bych tam mohl nekdy nagenerovat nekdy nejake 'fake' navic a zkusit, co to udela), ale kdybych si nabihal na problem tam, asi si zacnu hrat s hashovacima filtrama u tc, ktere vidim jako rozumnou cestu dal az to skutecne bude problem...
Reseni Promethea nad stovkama pravidel mi zrovna na tohle neprijdou moc efektivni (s tim, ze tc musi mit take nejakou tabulku, kde z iptables marku pozna, kterou tridu pouzit; takze se ve finale podstate prochazi dve tabulky - jedriv markovaci v IPT, pote dalsi filter v tc, ktera u tech fw flowid rozhodne hashovana nebude), ale to je spis subjektivni pocit (kdyz vidim - pokud dobre koukam - jak to je napsane; iptables v prometheu jsou sice v nejakem stromu, ale tc filter je placata tabulka), nemuzu potvrdit nejakym merenim.
PS: Ze to na brane je v posledni dobe prepsane do HFSC+ESFQ je asi nepodstatne, chtel sem si pohrat
load average: 0.00, 0.00, 0.00, aktualne cca 80Mbps
Finta fň je pouzit hashovaci algoritmus v TC a minimalizovat pouziti iptables, vyuzil jsem napad Mnagy, kdy mam defaulni tridu s nulovu rychlosti a neregistrovany IPcka padaji do ni.
Natku asi jinak nez pres IPtables nejde, nemel jsem zatim potrebu to dal optimalizovat, verejnych natuju cca 250, zatim mam linearni retez, ale urcite casem prejdu na stromecek.
Zkusebne jsem pres to protlacil cca 300Mbit, vic jsem nezkousel.
Mam jeden rack na firewally a pred tim router, pokud by mi nestacil vykon, tak jenom pridam dalsi firewall a na routeru source based routingem poslu cast provozu pres druhy router. Takhle to lze delat donekonecna a pokud se router zdvoji pres vrrp tak pomoci jednoduchych scriptu je mozny mit luxusni zalohu.
Sitovky na PCI-E, propustnost je dulezita, tak proc se limitovat PCI sbernici, kdyz stoji par drobnych navic.
A samozrejmne 2.6 jadro a irq balance.
Jo a vyhodil bych to SFQ v jednolivych tridach, pokud v dane tride sedi jeden uzivatel, tak neni duvod aplikovat na to jinou nez li standartni frontu FIFO, neco malo vykonu usetris.
Simandl: ten tvůj script je prima na tranzit. Jenže podle mě je pro gateway lepší řešení prometheus (je prostě férovější k userům).
Danny: zatím nikdo nepotvrdil, co přesně tc filtr používá za tabulky. Pokud u32 ip dle někoho hashovací tabulka je, tak se mi nezdá, že by nebyl hash i pro tento fw mark způsob.
Potvrdit by se to dalo asi přepsáním MARK iptables pravidel na CLASSIFY a vyhozením tc filtru. Zatím jsem se k tomu ale nedostal.
Největší problém asi bude to "přehazování paketů" mezi jednotlivýma classama.
A pro ostatní ... bohužel při řekněme 30Mbitech bych to neřešil. Tenkrát to bylo relativně v pohodě i na slabším stroji. Nemluvě o tom, že je potenciálně možné jít daleko výš.
RYS: bohužel to s tím přerušením asi už při těchto rychlostech moc platit nebude. Samozřejmě že má každá síťovka jiné ... a dokonce každé padá na jiný procesor. Ani nevím jak bych to měl překonfigurovat ... když vidím IRQ 1 - 22. A nic sdíleného ... Ale jinak to jsou opravdu všeobecná pravidla, které se člověk snaží dodržovat. Nic jiného, než Intel bych tam nedal ani za zlaté prase ... máme jenom jeden neintentel "server" a nejradši bych ho rozšlapal.
danny&belgarat: teď by mě zajímalo, kdo z vás má pravdu :-)
belgarat only: je mi jasné, že ty iptables něco stojí. Jenže dle mojich pokusů to rozhodně není úzké hrdlo. Dokonce i obecné firewally mám postavené velice podobným stylem a jsou schopné uroutovat cca 300Mbit (na podobném stroji). Tj. pokud máš pravdu s hashem na fwmark (asi jo) a já dobře chápu hashtabulky, tak je problém někde v tom htb nebo sfq.
Vůbec se do toho zamotávám ... experimentoval jsem s hodnotou BURST. Při 32k na všech třídách jsem měl pocit, že to jede lépe, ale vytížení šlo ještě trochu nahoru. Druhý krok 8k (bývalo 16) - vypadalo to také normálně, vytížení trochu kleslo, ovšem do doby špičky - graf přenosů byl naprosto vodorovný, propustnost se zasekla někde u 38Mbit.
Nejlépe jsem dopadnul s hodnotama 64k na class 1:1 a 1:2 (viz můj příklad) a 32k na 1:64, 1:66 a 1:256. Zbytek jsem nechal na 8k. Povedlo se nám z linky vytlačit cca 95Mbit. Pingy na seznam šly sice až někam k 30ms, ale jelo to vcelku dobře.
Objednal jsem síťovku Intel PRO/1000 PT Dual. Tak jsem na to zvědavej ... za ty tři tisíce ten pokus stojí.
shake: realteky tam nemám!!! :-) I v současném stavu je vše intel, obě gigové - integrovaná PCIe, druhá na PCI. Intel PRO/1000, přesnou verzi nevím ...
Nenapsal jsi, kolik tříd máš, ani jakou kapacitu qosuješ ...
Na tomto stroji máme normální intelí board. Čipset 965. Otázkou je, jestli jsou na tom lepší, serverové, desky o tolik lépe. 100Mbit není zase tolik, když se to vezme kolem a kolem ...
Ohledně PCIe a PCI-X bych zase věřil spíš tomu expressu. Má to míň drátů a není to sdílená sběrnice.
Jestli to dobře chápu, tak pokud vynechám "qdisc add", tak se používá pfifo_fast. Sice to netestuju ve špičce, ale vliv to evidentně nemá žádný ... 30% obě jádra před i po.
To je špatný ... spíš jsem myslel, že problém je SFQ.
26.11.2007 v 11:10
