classic.ISPforum.cz

Ahoj, po změně hraničního routeru na CCR1036 a náhradou SQ za mangle+QT se vytížení CPU docela razantně zvedlo. Při toku kolem 400Mbps kolem 35%.
- mangle 1300
- UT (up+down) 1200

Koukal jsem po pár tématech a doporučuje se optimalizace. Nějaký typ na správnou optimalizaci? Nebo by byl někdo ochoten dát k dispozici přístup "na kukačku" ( viewtopic.php?f=6&t=24492 )

Díky všem za typy a rady.

Z.

Možná to nebudeš chtít slyšet, ale QT + mangle je pro CCRko zabiják už právě při takhle malých rychlostech. Schválně se nedívej jen na "celková procenta CPU", ale mrkni se na jednotlivá jádra a uvidíš co to s tím dělá. Optimalizovat můžeš akorát tak mangle, aby nebylo nutné prolézat celou tabulku.

CCR je absolutně nevhodne na shaping. My teď dělali před tokem server stal asi 25k-30k což je skoro jak CCR 1036 a jede prez nej 1.5 Gbit, firewall, 2400nat,2400mangle a 2800 queue a cpu 20% max.

Na shaping je potřeba jádra o co nejvyšším taktu a síťovkou co umí frontovat packety.

Základní optimalizaci udělal sám mikrotik - a to v SQ. Jelikož zkonstatoval, že QT se na víc jader optimalizovat v podstatě nedají.

Petr Bačina píše:Možná to nebudeš chtít slyšet, ale QT + mangle je pro CCRko zabiják už právě při takhle malých rychlostech. Schválně se nedívej jen na "celková procenta CPU", ale mrkni se na jednotlivá jádra a uvidíš co to s tím dělá. Optimalizovat můžeš akorát tak mangle, aby nebylo nutné prolézat celou tabulku.

No právě proto bych rád zkusil základní optimalizaci a potom se uvidí. Proto hledám možnost jak provést optimalizaci manglu.

Já tedy do Mikrotiků do hloubky nevidím, ale jak to tady už delší dobu sleduji, tak evidentně platí pravidlo že MK != shaper.
Jen koukám, jak to tady další a další zkouší a zkouší, a pak to tu řeší a řeší.
Není lepší za ty prachy koupit normální stroj? Tedy pořádná SMikro deska, pořádnej Xeon na vysoký frekvenci, Linux, a hotovo?

svestka píše:Já tedy do Mikrotiků do hloubky nevidím, ale jak to tady už delší dobu sleduji, tak evidentně platí pravidlo že MK != shaper.
Jen koukám, jak to tady další a další zkouší a zkouší, a pak to tu řeší a řeší.
Není lepší za ty prachy koupit normální stroj? Tedy pořádná SMikro deska, pořádnej Xeon na vysoký frekvenci, Linux, a hotovo?

No lepší to asi nejspíš je, ale je již více jak 0,5roku tento MK na místě a přechod si vyžádala lepší analýza paketů.

A co požíváte za HW a SW pro shaper vy?

Zatím ROS na x86, ale tohle je moc pěkné https://www.unitednetworks.cz/projekty/isp-gateway/

ludvik píše:Základní optimalizaci udělal sám mikrotik - a to v SQ. Jelikož zkonstatoval, že QT se na víc jader optimalizovat v podstatě nedají.

To je zvláštní, že na x86 není problém. 16 jader to vytěžuje dost rovnoměrně, problém je, že samotné jádro je příliš slabé -> nedá takový tok, jaký bys očekával - gigabit

svestka píše:Já tedy do Mikrotiků do hloubky nevidím, ale jak to tady už delší dobu sleduji, tak evidentně platí pravidlo že MK != shaper.
Jen koukám, jak to tady další a další zkouší a zkouší, a pak to tu řeší a řeší.
Není lepší za ty prachy koupit normální stroj? Tedy pořádná SMikro deska, pořádnej Xeon na vysoký frekvenci, Linux, a hotovo?

kraviny. CCR != shaper. 99% ISPíků jede na shaperu na mikrotiku a neřeší kraviny. Dneska už stařičkej xeon e3 haswell nám točí 800Mbit pro cca 1000 lidí se zátěží kolem 20-25% s mangle + qt + nat a problém po optimalizaci mangle není absolutně žádný. Proč se hrabat v linuxu fakt nevim.

soooc píše:

ludvik píše:Základní optimalizaci udělal sám mikrotik - a to v SQ. Jelikož zkonstatoval, že QT se na víc jader optimalizovat v podstatě nedají.

To je zvláštní, že na x86 není problém. 16 jader to vytěžuje dost rovnoměrně, problém je, že samotné jádro je příliš slabé -> nedá takový tok, jaký bys očekával - gigabit

load.png

pro mikrotiky neni priorita prodávat licence za pár šušňů ale CCRka za těžký prachy ačkoliv cena toho CPU neni ani desetinová. QT samozřejmě běží na víc jádrech... rozuměj 4 QTčka běží na 4 jádrech což SQ předtím neumělo a běželi všechny na jednom. Proto se mikrotik chlubil že vymazlil SQ protože SQ je jejich výmysl. Ale i tak na něj platí omezení o max průtoku skrz jednu SQ. Jenomže většina lidí si koupila CCR s tím že chce shaping a většina takových používá SQ takže se na ně snesla kritika že to nedává když se posadí na jedno jádro. Pouze v tomhle tkví optimalizace SQ.

Každopádně si nemůžu nevšimnout že ani jeden příspěvek neodpovídá na otázku ale pouze na kritizování toho že máš CCR. Jo je to tu na úrovni.

kraviny. CCR != shaper. 99% ISPíků jede na shaperu na mikrotiku a neřeší kraviny. Dneska už stařičkej xeon e3 haswell nám točí 800Mbit pro cca 1000 lidí se zátěží kolem 20-25% s mangle + qt + nat a problém po optimalizaci mangle není absolutně žádný. Proč se hrabat v linuxu fakt nevim.[/quote]


Píšeš optimalizace mangle, ale jak? Co je tím správným směrem? jumpy?

Ano, např. jump na základě podsítí do správné kategorie .... prostě aby packet nemusel procházet moc manglů před sebou (místo historického stylu co jedna ip to mangle v kořeni). Mimochodem MK v CCR o dost vylepšil SQ a SQ v kombinaci s parent už jsou výkonné dost.

Možná QT (tedy HTB) též trochu optimalizovali (také bude nejspíš závislost na typu leaf třídy). Ale nic to nemění na tom, že prakticky nezáleží na množství SQ (jen logicky na množství dat), kdežto složitému QT roste náročnost na CPU podstatně rychleji (zvlášť když k tomu potřebuji mangle a nemám target CLASIFY).
Nevím kde končí použitelnost CCR pro shaping. Takto to nepoužívám. Někde bude to jedno jádro mít strop a bude určitě níže, než jedno x86. Ale zase jich je víc. Pak jde o to si rozhodnout, jestli to stačí ... Já bych to jako centrální shapper nepoužil.

Optimalizace mangle spočívá v "index stromu" jak tomu říkal xChaos Paket postupně skáče po větvích stromu tak, aby žádný nešel přes víc jak pár pravidel. Pro síť /16 to bylo optimální tak, aby poslední chain v cestě byl /29.