Společnost OpenAI představila GPT-5 (YouTube).
Byla vydána (𝕏) červencová aktualizace aneb nová verze 1.103 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.103 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Americký prezident Donald Trump vyzval nového generálního ředitele firmy na výrobu čipů Intel, aby odstoupil. Prezident to zdůvodnil vazbami nového šéfa Lip-Bu Tana na čínské firmy.
Bylo vydáno Ubuntu 24.04.3 LTS, tj. třetí opravné vydání Ubuntu 24.04 LTS s kódovým názvem Noble Numbat. Přehled novinek a oprav na Discourse.
Byla vydána verze 1.89.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Americká technologická společnost Apple uskuteční v USA další investice ve výši sta miliard dolarů (2,1 bilionu korun). Oznámil to ve středu šéf firmy Tim Cook při setkání v Bílém domě s americkým prezidentem Donaldem Trumpem. Trump zároveň oznámil záměr zavést stoprocentní clo na polovodiče z dovozu.
Zálohovací server Proxmox Backup Server byl vydán v nové stabilní verzi 4.0. Založen je na Debianu 13 Trixie.
Byla vydána nová verze 1.54.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Jan Václav.
Knižní edice správce české národní domény přináší novou knihu zkušeného programátora Pavla Tišnovského s názvem Programovací jazyk Go. Publikace nabízí srozumitelný a prakticky zaměřený pohled na programování v tomto moderním jazyce. Nejedná se však o klasickou učebnici, ale spíše o průvodce pro vývojáře, kteří s Go začínají, nebo pro ty, kdo hledají odpovědi na konkrétní otázky či inspiraci k dalšímu objevování. Tištěná i digitální verze knihy je již nyní k dispozici u většiny knihkupců.
OpenAI zpřístupnila (en) nové nenáročné otevřené jazykové modely gpt-oss (gpt-oss-120b a gpt-oss-20b). Přístupné jsou pod licencí Apache 2.0.
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
marekDekuji 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
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: yesa není potřeba nic zachytávat tcpdumpem.
unbound-control stats_noreset
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
marekDekuji 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.
marekProsim 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
Tiskni
Sdílej: