Solved Chromium slow

i believe that could be the case for me too, which i'd guess it actually comes from the journaling updating the journal every minute or so, and so there'd be times where the information was so much to write that the system'd freeze for that tiny amount of time

maybe i should try booting with journaling disabled to confirm, shouldn't hurt to try right
 
UPDATE: i currently have journaling disabled right now and it seems to have gotten just a little better, what even is the rationale behind having soft-updates and journaling enabled at the same time anyways

however i just noticed this little process running in the background, syncer, which apparently is responsible for "flushing volatile cached file system data to disk" every moment
i guess this one is the bigger culprit here then? not really sure how to check processes by drive I/O so i'm guessing stuff again
 
I'm no expert, but iostat -w 1 will at least print out io information every second, so you could have numbers. Perhaps you can relate that to running processes such as syncer.
 
well it doesn't say which process is causing such I/O spikes, but i guess it should at least be good enough to confirm that the lagging might be because of that
 
UPDATE: i was right:

1761517194565.png


523.90 MB/s··· this is literally ~95% of my SSD's speed··· what the hell could possibly be writing so much data to it?
i wonder if there's a way to list processes by how much I/O they're using
 
Some browsers do different stuff with different Xorg DDX (Firefox software-renders if using Intel DDX but hardware-accels with modesetting; there could be other things with amdgpu vs modesetting and NVIDIA)
 
i see, well i was able to reduce the issue even further by changing the following sysctl parameters:
Code:
# try increasing the file limits
# so that i (might) get a smoother
# experience on chromium
kern.maxvnodes=1048576 [original was 520k-ish]
kern.maxfiles=524288 [ditto]

# try increasing my SSD's
# performance too
vfs.read_max=128 [original was 64]
not sure what exactly about these made it work better but hey they did
i might try to keep messing with those numbers until i completely eliminate the issue, for now i seem to be on the right track

also,
Firefox software-renders if using Intel DDX but hardware-accels with modesetting
what exactly does that mean? is it why i don't get hardware acceleration at all in firefox, even tho' i even have FFmpeg compiled with VA-API/Vulkan support enabled?

EDIT: just found out, i checked sysctl vfs.numvnodes and that shit was at nearly half the original value of vfs.maxvnodes, so i guess that tunable was already enough to help
 
what exactly does that mean? is it why i don't get hardware acceleration at all in firefox, even tho' i even have FFmpeg compiled with VA-API/Vulkan support enabled?

In about:support a little down there's Graphics -> Compositing; it'll have just WebRender if it's hardware-accelerated (no "Software" mention)

Firefox's graphics blocklist disables hardware-acceleration if Intel DDX is used on Xorg (likely bugs). Setting about:config -> gfx.webrender.all true force-enables hardware-acceleration. The default DDX is modesetting and shouldn't be blocked from hw-accel.
 
not sure what exactly about these made it work better but hey they did
it seems that vfs.maxvnodes opens up more space for programs to create more and more files, which untightens my SSD

so now i wonder what the best value for that would be··· i can't just randomly increase this, and i'd guess there is some sorta formula that takes the total capacity of the desired partition and the average size of its files to then yield the maximum number of vnodes i could theoretically have
 
chromium does throw some files to /tmp, but they seem to be related to the current site's cookies and stuff
firefox stores the cache on RAM so i guess this could somehow be done here, like with an extension or maybe a daemon
 
well here's the thing, /tmp/ gets cleared on every boot, and the cache is actually important to maintain a consistent speed when loading webpages
i'm pretty sure firefox stores the current cache to /tmp/ and then it writes it to ~/.cache/mozilla/ before exiting, so there should be a wrapper script that not only changes the cache directory to that but also writes the changes to the persistent storage every time the user exits Chromium
 
So, you're asking someone here to write a script that does that?

Alternatively, why not raise a bug report upstream and explain how it is impacting you and unnecessarily wearing your your SSD. I think that can be achieved with a wrapper script.
 
So, you're asking someone here to write a script that does that?
nah it was just a suggestion, i can write one myself

Alternatively, why not raise a bug report upstream and explain how it is impacting you and unnecessarily wearing your your SSD. I think that can be achieved with a wrapper script.
yeah i guess i could do that
Gentoo for example does ship Chromium with a wrapper script for it, tho' not exactly for that purpose
 
Back
Top