Deduplikace: Difference between revisions
No edit summary  | 
				No edit summary  | 
				||
| Line 1: | Line 1: | ||
'''use_block'''  | '''use_block'''  | ||
- mód byl udělán pro zvýšení výkonu  | - mód byl udělán pro zvýšení výkonu  | ||
- v něm se načtené pakety ukládají do předalokovaného bloku pro více paketů, pak i ve zpracování v t2 threadech se pracuje s ukazatelem na ten jeden velký blok  | - v něm se načtené pakety ukládají do předalokovaného bloku pro více paketů, pak i ve zpracování v t2 threadech se pracuje s ukazatelem na ten jeden velký blok  | ||
- tedy navýšil se tím výkon a pak zanedlouho se dělaly optimalizace v t2 threadech, které taky nějaké úspory přinesly,a protože se zdálo zbytečné aby ty dva optiony byly odděleny, zapíná se to dohromady přes option t2_boost.  | - tedy navýšil se tím výkon a pak zanedlouho se dělaly optimalizace v t2 threadech, které taky nějaké úspory přinesly,a protože se zdálo zbytečné aby ty dva optiony byly odděleny, zapíná se to dohromady přes option t2_boost.  | ||
Nasel jsem tyto optiony se automaticky nastavuji pri t2_boost=yes:  | Nasel jsem tyto optiony se automaticky nastavuji pri t2_boost=yes:  | ||
| Line 16: | Line 19: | ||
''opt_preprocess_packets_qring_item_length = 5000''  | ''opt_preprocess_packets_qring_item_length = 5000''  | ||
'''udpfrag'''  | '''udpfrag'''  | ||
- defragmentace a deduplikace se původně pouštěla jen ve čtecích threadech samostatně za každé rozhraní (t0,t1)?  | - defragmentace a deduplikace se původně pouštěla jen ve čtecích threadech samostatně za každé rozhraní (t0,t1)?  | ||
- konkrétně defragmentace byla problémem, protože by se rozbil koncept předalokovaného bloku načtených paketů - v ní je potřeba pořád nějaké pakety skládat do alokovaných výsledných paketů s celkovým obsahem  | |||
proto se pro (pcap_queue_use_blocks = true) přesunula defragmentace až do spojení bloků z více rozhraní - navíc to tedy přineslo možnost defragmentovat obsah z paketů z více rozhraní  | - konkrétně defragmentace byla problémem, protože by se rozbil koncept předalokovaného bloku načtených paketů - v ní je potřeba pořád nějaké pakety skládat do alokovaných výsledných paketů s celkovým obsahem, proto se pro (pcap_queue_use_blocks = true) přesunula defragmentace až do spojení bloků z více rozhraní - navíc to tedy přineslo možnost defragmentovat obsah z paketů z více rozhraní  | ||
'''deduplikace'''  | '''deduplikace'''  | ||
- defragmentace a deduplikace se původně pouštěla jen ve čtecích threadech samostatně za každé rozhraní (t0,t1)?  | - defragmentace a deduplikace se původně pouštěla jen ve čtecích threadech samostatně za každé rozhraní (t0,t1)?  | ||
- pri (pcap_queue_use_blocks = true) se deduplikuje i po spojení bloků z více rozhraní (nebo klientů)  | - pri (pcap_queue_use_blocks = true) se deduplikuje i po spojení bloků z více rozhraní (nebo klientů)  | ||
'''  | |||
'''shrnuti'''  | |||
- use_blocks mód zvyšuje výkon čtecích threadů  | - use_blocks mód zvyšuje výkon čtecích threadů  | ||
- t2_boost zvyšuje výkon t2 threadů a navíc zapíná use_blocks mód  | - t2_boost zvyšuje výkon t2 threadů a navíc zapíná use_blocks mód  | ||
- bez zapnutého use_block módu není možná defragmentace a deduplikace z více rozhraní  | - bez zapnutého use_block módu není možná defragmentace a deduplikace z více rozhraní  | ||
- pokud se zapne auto_enable_use_blocks = yes, zapne si sniffer use_block mód sám, když je požadavek defragmentace nebo deduplikace a je zároveň více rozhraní nebo jde o server/receiver mód  | - pokud se zapne auto_enable_use_blocks = yes, zapne si sniffer use_block mód sám, když je požadavek defragmentace nebo deduplikace a je zároveň více rozhraní nebo jde o server/receiver mód  | ||
Revision as of 18:42, 25 April 2018
use_block - mód byl udělán pro zvýšení výkonu
- v něm se načtené pakety ukládají do předalokovaného bloku pro více paketů, pak i ve zpracování v t2 threadech se pracuje s ukazatelem na ten jeden velký blok
- tedy navýšil se tím výkon a pak zanedlouho se dělaly optimalizace v t2 threadech, které taky nějaké úspory přinesly,a protože se zdálo zbytečné aby ty dva optiony byly odděleny, zapíná se to dohromady přes option t2_boost.
Nasel jsem tyto optiony se automaticky nastavuji pri t2_boost=yes:
opt_enable_process_rtp_packet = 1
opt_pcap_queue_use_blocks=1 // pokud neni sender, ani scanpcapdir
opt_process_rtp_packets_hash_next_thread = 2
opt_process_rtp_packets_hash_next_thread_sem_sync = 1
opt_preprocess_packets_qring_length = 4 // 3 jen pokud je rucne definovan (process_rtp_packets_qring_length > 2000 || opt_process_rtp_packets_qring_item_length <> 0)
opt_preprocess_packets_qring_item_length = 5000
udpfrag
- defragmentace a deduplikace se původně pouštěla jen ve čtecích threadech samostatně za každé rozhraní (t0,t1)?
- konkrétně defragmentace byla problémem, protože by se rozbil koncept předalokovaného bloku načtených paketů - v ní je potřeba pořád nějaké pakety skládat do alokovaných výsledných paketů s celkovým obsahem, proto se pro (pcap_queue_use_blocks = true) přesunula defragmentace až do spojení bloků z více rozhraní - navíc to tedy přineslo možnost defragmentovat obsah z paketů z více rozhraní
deduplikace - defragmentace a deduplikace se původně pouštěla jen ve čtecích threadech samostatně za každé rozhraní (t0,t1)?
- pri (pcap_queue_use_blocks = true) se deduplikuje i po spojení bloků z více rozhraní (nebo klientů)
shrnuti
- use_blocks mód zvyšuje výkon čtecích threadů
- t2_boost zvyšuje výkon t2 threadů a navíc zapíná use_blocks mód
- bez zapnutého use_block módu není možná defragmentace a deduplikace z více rozhraní
- pokud se zapne auto_enable_use_blocks = yes, zapne si sniffer use_block mód sám, když je požadavek defragmentace nebo deduplikace a je zároveň více rozhraní nebo jde o server/receiver mód