Fórum Root.cz
Hlavní témata => Software => Téma založeno: Ħαℓ₸℮ℵ ␏⫢ ⦚ 11. 07. 2025, 14:39:56
-
Proč! chromium při uploadu 3-4 MB/s zatěžuje CPU 50% agregovaně? Zatěžuje hlavní parentproces chromu, jde o E2E upload. 90% zátěže je Kernelo load (červená), zelená (user) je takový kopeček celku,, nebo jinak, 3 jádra jsou z 50% červeně (kousek nad tím troška zeleně) a čtvrté jádro z 25% červeně, OS Win7. rychlost 2GHz i7 Haswell. Jiné procesy v systému mají <1%, celkem tak pod 5%.
-
Napadá mě spousta možností.
USB úložiště s transparentní kompresí, USB síťovka, průběžná kontrola antivirem, řízení USB hubu procesorem, blbě napsané ovladače hardwaru kterým to protéká, nějaká fancy animace průběhu v prohlížeči bez akcelerace efektů na GPU, efekty GUI bez akcelerace, odkládání odesílaných dat do mezipaměti kdovíkde, ideálně na MMC připojené přes USB ...
-
Nevím proč, ale toto se mi děje i při downloadu. Stačí stahovat třeba 4 soubory trochu rychlejší linkou a CPU hoří.
-
No to spousta nápadů, některé hned vyvrátím , ale některé na to káply.
- úložiště je NAS windows share na gigabitové integrované intel síťovce. z lokálního disku není problém!
- antivir neužívám
- USB hub nemám (ale mám zkušenosti že obecně někdy USB síťovky zatíží hodně CPU)
- animaci tabu jsem taky uvažoval, někdy tohle dokáže z chromáku udělat topné tělěso, ale není to ten případ, tab byl i v pozadí
...emmc problémy bych viděl na nedospělách computerech typu RPI, kde kombinace datový provoz z microSD přes integrovanou wifi udělá kernelový holocaust., obojí SDIO/mmc sběrni e
Ale je řeč o 32Mbps, což zvládne i raspberry bez nějakého povšimnutí cpu load, natož x86 + pcie/msata
zkoro bych z toho chrom vyloučil, když se z C:\ problém zmizel
PS: v obou případech (z C:\ i z \\nasu při uspání notebooku při uploadu a probuzení dojde webová aplikace zahodí upload a vypíše "že nastala chyba ??? ) ... kdybych tohle ku***va věděl, tak bych mohl býval zkusit pomocí task manageru suspendnout nejdřív ten hlavní proces chromu ... netvrdím, že by to pomohlo, ale stejně jsem si takový experinent v aktuálním stavu množství tabů browseru nemohl dovolit)
>anonacct, ale bez popisu problému hw, rychlostí a browseru, os, je to jen obecný povzdech...
-
OS Win7. rychlost 2GHz i7 Haswell.
Pises 4 jadra HSW ale i7/2GHz.. to bude spis mobilni 2 jadro s HT. Mas performance power profil nebo powersave? Tj. zda to nezevli zbytecne na male frekvenci, a dokud neni na 100 procent vyuzite nejake jadro jednim vlakem, tak OS neni ochoten zvednout frekvenci?
PS: v obou případech (z C:\ i z \\nasu při uspání notebooku při uploadu a probuzení dojde webová aplikace zahodí upload a vypíše "že nastala chyba ??? ) ...
Uspani notebooku narusi TCP spojeni, ze padne HTTP/s v brosweru je tedy spravne.
Treba na macu se napise "nastala chyba" i z duvodu ze na disku neni dost mista.. tohle nam zabralo pul dne zjistit - ono to totiz nereklo ze to je mistem na disku.. spis se to tvarilo ze se nemuze pripojit k te URL a zacit :D
-
Tak se na ten CPU load mrkni, Process Explorer... a tam hned uvidis, jestli ty casy jadra jsou Interrupts, nebo treba proces System (kteryzto si muzes rozkliknout a nahlidnout do Threads, jestli z nej nevyctes ovladac, kterej ten load zpusobuje).
Od toho se muzes odpichnout dal...
-
TLDR +:; ještě že jsem si zkopíroval příspěvek, protože po odesálání:litujeme, přístup odepřen. až budu připojen kabelem, kouknu na threads chromu a zkusim jestli jestli i jiný proces (ne chrome, ale kopírování přes explorer atd) to nevytíží - protože na wifině není problém , to asi naznačuje, že jakýkoli proces používající ten ethernet by generoval ten cpu load.
Díky za podněty ještě jedna horká novinka, při použití wifiny (1 MB/s -blbý signál)se to neděje,ale jen s intel Ethernetu(4MB/s) intel i 218LM). Jasně že rychlost je čtvrtinová, ale CPU load u chromu.exe není 50/4 ale "1%" nebo "<1%", píšu ,že zátěž je výhradně chromium.exe, nic jiného ani z těch pseudoprocesů, Threads jsem nezkoumal, v tu už jsem přišel na to ,že to je při uploadu z \\smb jen. Napadá mě nějaké použití šifrování SMB,jestli něco takového u SMB je ale pochybuju, proč v lokální síti by na který je SMB určen používalo šifrování, to nedává hlavu a patu (což ale je ve sporu s wifi/ethernet)
A ještě vyvrátím to škálování CPU frekvence, to si samozřejmě hlídám, když zkoumám CPU load. ano je zamčený na PP1 (1.8GHz) aby zbytečně nežral, ale ono není o co stát, PP2 je 2.3GHz a bez locku asi 2.5GHz, jádra jedou na těch 1800
power performance trace profil chromu jsem nedělal, protože jednak by mi mohl crashnout, ono to sežere dost RAM a zadruhé už mám pocit, že možná chromem to není, jestliže to wifina to nedělá a gigabit ethernet obnoard ano.
parametry sítoveho adaptéru upřesnit konfigurovat
flow control off
ale všiml jsem si že speed&duplex není auto ale 100Mbps half, ale nevím jestli to není bug toho dialogu/hodnot a reálně rychlost by byla gigabit(ono je to stejně jedno, LAN je gigabitová, ale router 100mbitem do switche) a už nechci zase chodit s kabelem a koukat
chtěl jsem se podívat jestli je povolen offload tcp nebo ten čimny,ale to netsh je takový bordel, že myslím, že bych vyčetl stav pro tcp stack a ne pro síťovku(se kterou nejšem připojen momentálně)
-
u sitovky muzes zjistit, zda je zapnuto interrupt coalescing, ale to je spis potreba u 10G, vetsinou ty PCH sitovky s PHY nemivaj problem.. zkousel jsi overovat zda nejsou spatne treba pakety? zadny filtr v OS neni na rozhrani?
jinak bych zacal tim, ze stejny URL zkusim pres WGET. Pokud se to dramaticky lisi od chrome, tak proste chrome ja na vine.
PS. Chrome nepouzivam. Je to zlo :D
-
Tak trochu mimo problemu, ped par rokmi som si vsimol, ze chrome nezvlada vela tabov (stovky), firefox v pohode 1000+ tabov. Chrome rychlo zapratal celu ram 16GB aj vytazoval CPU. Ale zas poslednu dobu si vsimam, ze webgl ide lepsie na chrome ako na firefoxe.
-
a je to nějaké stejně shnilé i na jablku. Chrómium při uploadu z smb share z OS X přímo z umístění, které bylo "mountnuto" {přes Finder ... Připojit k serveru } uploaduje rychlostí držte si klobouky 538 kb/s až 820 kb/s. Lokální soubor 26 Mb/s.
a logicky jsem připojen přes drátový USB ethernet (jelikož Apple na 802.3 hází bobek), protože na slabé wifi by byla šílenost tahat data do noťasu znasu a do internetu přes tu samou wifi zatěžovat wifi full duplex
Takže hádám, že problém bude v chromu , pro jistotu to zkusím i přes wifi, protože externí síťovky dokážou Applu docela zatopit a dám vědět : rychlost je 256 kb/s, kernel_task 33% ,chromium 4%, window server 4% (z LAN) je tam i handicap dělení duplexu wifi ale tohle jsem nečekal. Lokální soubor frčí přes wifi 5 Mb/s.
cpu load je 12.5 chromium a 11.9 kernel_task (jde o intel 4jádro x HT) při uploadu přes drát.
Tak se ptám, jací soudruzi (apple, chrome, nebo něco jiného) udělali chybu a kde.
Stejný soubor si z LAN na tom OS X v přes VLC přehraju ok, seeky jsou instantně , jde o bitrate 25-40 Mbps
abych byl fér, na armu s linuxem(mate) upload lítá plnou rychlostí, ale CPU load tvoří hlavně nějaké gvfs_smbd a gvfs_fuse, celkem to asi zatíží 5O% cpu toho armu a to sou jádra mezi 1 a 2 GHz ,celkem 8. síťovka je integrovaná na tom armu nějaký realtek.
taky chromium.
-
A ještě aby to bylo kompletní, na tom posledním příkladu (odstavec ...abych byl fér...) při mountnutí lokace přes mount.cifs je zatížení procesoru na tom 8jádrovém armovém miniPC při downloadu z SMB nasu + uploadu přes i současně oběma směry rychlostí 20Mb/s integrovaný gigabit rozhraním (to ale nehraje roli)
prakticky jen chromem, musel jsem zapnout kernel threads (Shift K ),
abych viděl, že cifs žere 3-5% a kworker cifsiod asi 0.7%
-> takže i metoda přístupu k smb hraje roli.
zatímco chrome asi 3 procesy 20,30 a 50% nebo 2 procesy 20% a 40% (a ještě kdy je přepnuto na "mrtvý" tab)
Předtím na tom minipc to bylo mountnuté out of box přes ty fuse / Gvfs moduly gnome a to samo o sobě taky vytížilo o 2 jádra navíc
(nezapomenout, že jediný windows hlásí cpu load dělený počtem jader)