Dotaz: tcpdump/netsniff-ng performance

[marek]

Dobry den.

Pisu nastroj na statistiku odezvy udp provozu dns cache.

Server ma 2 provozni sitove karty - dotazy mohou prijit po jakekoli, odpovedi mohou odejit take po jakekoli.

Server ma vetsi mnozstvi ip adres na kterych odpovida.

Server ma vice views, jsou rozdelene dle rozsahu, ze ktereho jde dotaz.

Zajimaji mne statistiky pro kazdou adresu serveru a pro kazdy view.

Mam hotovy prototip mereni:

Vzdy 2 parove tcpdumpy s omezenim na view a sitovku (mam 2 sitovky), ktere pomoci pipe posilaji pcap data scriptum, ktere dotaz rozparsuji(ip/udp/dns) a posilaji unix sockety dalsim procesum, ktere:

si drzi okno dotazu a prirazuji jim odpovedi, odecitaji z pcapu rozdil casu a na vyzadani vypisuji statistiky.

Zda se, ze vse funguje jak ma, vzhledem k tomu, ze ma server dost zdroju, to vypada, ze si zatizeni ani nevsimne.

Jen mne trochu desi, ze tam bezi cca 90 procesu tcpdumpu s docela vyzivnym filtrem.

Muj dotaz tedy zni:

Tusite nekdo, zda vetsi mnozstvi spustenych tcpdumpu neudela v systemu nejake uzke hrdlo?

Pripadne zda je nejaky principialni problem tohoto reseni..... kde hledat?

Dekuji

marek

Odpovědi

[X]

Devadesat procesu tcpdump? Co to proboha ma byt? Misto vynalezani hranateho kola by jsi mohl nejdrive podivat na podobne projekty. Namatkou(5 min. hledani..):

https://github.com/CZ-NIC/respdiff

https://github.com/CZ-NIC/shotgun

https://github.com/CZ-NIC/dns-probe

[marek]

Dekuji za odpoved.

Bohuzel se obavam, ze mi prilis nepomuze.

Asi jsem zapomel zminit, ze ta cast se statistikama je zcela funkcni a vyhovujici.

Na serveru je takovy provoz, ze to stejne musi byt stejne napsano viceprocesove.

Na podobne projekty jsem se samozrejme podival, z nekterych ponaucil ...

Problem je v tom, ze prave nechci vynalezat hranate kolo, ale chci vyuzit filtry tcpdumpu.

Python je na moji ulohu pomaly, parser mam v golang a i tam jsem musel tvrde optimalizovat.

marek

[jejda]

Pisu nastroj na statistiku odezvy udp provozu dns cache.

Třeba takový unbound umí vypisovat hodně detailní statistiky i s histogramem odezvy. V konfiguráku nastavíš

extended-statistics: yes

a není potřeba nic zachytávat tcpdumpem.

unbound-control stats_noreset

[marek]

Bohuzel nas dns software sice histogram vypisuje, ale dolni mez je 1ms.

Do toho se vejde skoro vse, mimo erroru zpusobenych rekurzi.

Takze na vyhodnoceni zhorseni sluzby pri zatezi je to zcela nevyhovujici.

vrchol histogramu mam o rad jinde (0.000062500s)

Dale dotazovaci nastoj, ktery pouzivame na tvorbu statistik (dle adres serveru) ve spickach nestiha...

Dekuji

marek

[Max]

Pokud to chápu správně, tak máš spuštěných 90 tcpdumpů, protože proč přesně? Necháváš si od něj předparsovat data, aby jsi to pak měl v dalším kroku jednodušší? Nebo je to kvůli minimalizaci objemu předávaných dat?
Každopádně já v tom zas tak velký problém nevidím a ani mě nenapadá, kde by nějaké úzké hrdlo mohlo být. O sniff se stará kernel, takže pořád se sniffuje jen jednou a režie jakoby navíc má pak jen samotné parsování v rámci tcpdumpu, což by mělo ovlivnit jen výkon CPU. Ale třeba se pletu a někdo mě opraví.
Jinak na vnitřnosti kernelu ohledně síťování, je odborník Michal Kubeček :).
Zdar Max

[marek]

Dekuji za reakci.

Duvod proz pcap a ne rovnou sniff interface - je pak mozne delegovat vykon na jiny stroj (tcpdump muze bezet na vyrazne slabsi sonde nez parser/parovac/tvorba statistik.)

90 samostatnych vlaken vychazi z kombinace poctu views X pocet cilovych ip adres X pocet sitovych karet.

Minimalne mi tam musi bezet 2x equivalent tcpdumpu v kolone s parserem, protoze mam 2 sitovky.

Jenomze 2 procesy, kazdy na jednom CPU, nedaji dostatecny vykon.

Takze to stejne musim nekde paralelizovat.

Proto tam mam tu komunikaci pres unix sockety - protoze jsem to zacal psat v go, a pri testovani optimalizaci jsem zjistil, ze parsovani pcap streamu je nejrychlejsi jednovlanove pri uzamceni procesu na konkretni CPU.

Mohl bych to rozbocovat pri tom parsovani, ze bych to posilal na ruzne sockety, ale musel bych zajistit, ze dotaz i parova odpoved pujde na ten samy socket (treba dle srcip srcport dstip dstport hash - pro odpoved samozrejme obracene).

Dale bych musel stejne zajistit, ze se parser bude paralelizovat (pro dostatecny vykon). To bych asi resil s netsniff-ng a fanout.

A jeste je problem s definicema views. Je to docela dost rozsahu i s excludama, takze si napsat funkci, ktera rika pro konkretni IP do jakeho rozsahu patri je radove slozitejsi, nezli zbytek ulohy.

Proto jsem to zpocatku napsal pro kazdou ip adresu serveru, sitovku a view tcpdump->parser->parovac_dotazu_odpovedi/tvorba_statistik

Jenze to znamena 90 samostatnych vlaken.

Uzke hrdlo je parovac_dotazu_odpovedi/tvorba_statistik.

Ve spicce si to pri jednovlaknovem zpracovani bere okolo 60% procesosu. Mame pravidlo, ze bychom meli byt schopni odbavit 10-ti nasobek bezne spicky.

Parser si bere okolo 20% procesoru.

Takze 2 parsery na 1 parovac jsou asi tak akorat?

Z toho vyplyva ze 90 je asi kanon na vrabce, ale kolem 10-20 by to asi chtelo - urcite to rozlozeni nebude rovnomerne...

V tento okamzik to vypada, ze by mohlo vykonove stacit pouze kombinace poctu views X pocet sitovych karet X ipv4/6 X rozpuleni velkych views.

Akorat musim dopsat do tvorby_statistik, ze to ma pocitat pro jednotlive adresy serveru(tim zase trochu snizim vykon).

Zatim to testuji pri beznem provozu a predpokladane vysledky extrapoluji.

Testovaci scenar se stresovymi testy nebude vubec jednoduchy(vygenerovat dostatecny load).

Stejne mi tam ale nakonec zbudou vysoke jednotky instanci tcpdumpu, takze ma puvodni otazka stale plati.

marek

[Max]

Díky za info. Jinak moje odpověď také stále platí :).
Zdar Max

[X]

Hadam, ze pan programuje v aplikacni vrstve(PHP,JS) kde mu to chodi, ale ten podvozek naprasil skriptama a ted to ma nekdo posvetit.. Ne diky, radeji ciste reseni.

[marek]

Prosim co si predstavujete pod cistem reseni?

Zatim jsem nenasel nic, co by se architektonicky blizilo tomuto reseni.

Pokud nekdo o necem vite, sem s tim (proto se take ptam). Ty odkazy co Vam trvaly 5 minut resi bud jiny problem, nebo jsou vykonove o rad slabsi...

Zde se bavime radove o 300 000 dotazu za sec.

"Aplikacni vrsta" je v tomto pripade zabbix a influx/grafana oboje ma ve sprave nekdo jiny, ja mam pouze dodavat data.

Dekuji

marek