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.
Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
CCR1036 vytížení CPU
-
- Příspěvky: 1361
- Registrován: 9 years ago
- Bydliště: Horní Slavkov
- Kontaktovat uživatele:
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.
0 x
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.
Na shaping je potřeba jádra o co nejvyšším taktu a síťovkou co umí frontovat packety.
0 x
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í.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
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.
0 x
Zdeněk Kudrnáč - KudrnacNET - http://www.kudrnac.net
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?
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?
0 x
UPDATE klienti SET internet_povolen = false WHERE po_splatnosti > 500
Lepší než výhra ve Sportce :)
Lepší než výhra ve Sportce :)
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ů.
0 x
Zdeněk Kudrnáč - KudrnacNET - http://www.kudrnac.net
-
- Příspěvky: 1361
- Registrován: 9 years ago
- Bydliště: Horní Slavkov
- Kontaktovat uživatele:
Zatím ROS na x86, ale tohle je moc pěkné https://www.unitednetworks.cz/projekty/isp-gateway/
0 x
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
0 x
Petr Šlinz
UBNT mám rád!
UBNT mám rád!
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.
1 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
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.
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
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?
Píšeš optimalizace mangle, ale jak? Co je tím správným směrem? jumpy?
0 x
Zdeněk Kudrnáč - KudrnacNET - http://www.kudrnac.net
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.
0 x
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.
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.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.