monitoring stavu shaperu

[svestka]

máme na GW HTB, mašina je obyč 4 jádrový Atom, 2 integrované gbit síťovky, konektivita 400/400
v posledních dnech, ve večerné špičce, se dějí nehezké věci ... vytížení CPU je kolem 25%, pakety nevypadávají, jen přes shaper neleze co má. Když ho vypnu, celé se to probere a jede jak šlak, než torrenty u lidí pochopí že mají zelenou a pak je to na odstřel zase z druhé strany

potřeboval bych nějak monitorovat shaper v reálu, jak je která třída vytížená, kdo jede na garant, kolik zbývá k rozdání nad garant apod.
jak tohle řešíte?

díky moc

[ludvik]

Koupí výkonnější mašiny Teď. Dříve optimalizací.

[info@adambalko.cz]

Jednoznačně výkonnější stroj.

[svestka]

Jednoznačně výkonnější stroj.

koukám je to Atom D525@1.8GHz, 4-jádro, 2GB RAM - asi to fakt chce lepší mašinu, kdesi jsem tu o tom četl, nastuduji ... díky

nicméně zpět k tématu monitoringu shaperu ... řešíte to nějak? rád bych to měl pod kontrolou.

[info@adambalko.cz]

Zatím ne, je dost konektivity a nikdo si nestěžoval. Ale je to zajímavý námět. Díky

Jednoznačně výkonnější stroj.

nicméně zpět k tématu monitoringu shaperu ... řešíte to nějak? rád bych to měl pod kontrolou.

[Dalibor Toman]

potřeboval bych nějak monitorovat shaper v reálu, jak je která třída vytížená, kdo jede na garant, kolik zbývá k rozdání nad garant apod.
jak tohle řešíte?

díky moc

IMHO si myslim, ze tak maximalne graf dropu z shaperu (na MT sber takovych dat asi nepujde) - z toho by bylo videt, kde je jaka class pretizena. Sledovat kolik zbyva na rozdelovani asi nema smysl, protoze je to dost dynamicka zalezitost a vzorkovat to jednou za 5 minut nemusi byt vypovidajici.

[svestka]

nejde mi o grafovani atd., ale spiš o jednorazovou diagnostiku, když nastane problém

[ludvik]

Vývojář HTB na to něco používal ... ale co? Už nevím, asi si to budeš muset najít.

[Dalibor Toman]

nejde mi o grafovani atd., ale spiš o jednorazovou diagnostiku, když nastane problém

o nicem lepsim nez vycucavat informace z 'tc -s class show dev ethx' nevim.

Jinak co se tyce pretizene gatewaye je dulezite mit:
- vyresene sitove karty - tj mit nejake, ktere umi rozumny offloading na prijmu i odesilani. Tj rozhazovani packetu na ruzne IRQ a ty IRq pridelit jednotlivym jadrum
- optimalizovane iptables - eliminovat dlouhe chainy. Pouzit rozeskakovani po vetsich rozsazich (Ccko atd) ve filtrech pouzit ipset atd
- optimalizovany shaper - zase zamezit sekvencnimu prolezani filtru. Tj pouzit hash tabulky

Uz se to tady nekolikrat resilo. Nezminujes jestli ses tomu venoval...

Nakolik je to Atom schopny utahnout netusim. Ale mnozstvi casu straveneho obsluhou soft interruptu per jadra napovi, ze je neco v neporadku (bud neni optimailzovan filtering a shaper nebo procesor nestiha at diky malemu vykonu ci hloupe sitovce)

[milan.zelina]

Možná jsem vůl, dříve tady na foru býval HAPI,
který velmi dobře odpovídal na tyto dotazy,
kde je chyba?

[Dalibor Toman]

Vývojář HTB na to něco používal ... ale co? Už nevím, asi si to budeš muset najít.

asi mas na mysli ethloop (http://luxik.cdi.cz/~devik/qos/ethloop/). To je ale neco jineho - neslouzi k sledovani aktualniho stavu shaperu ale k testovani jeho chovani

[svestka]

kolega se té diagnostice zavěnuje hlouběji, moc díky za podněty.