Administrace komentářů

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.