Palemoon Portable components in low IO priority causing poor performance

For discussions specific to the Portable version of the browser.
Post Reply
User avatar
GogrillaMincefriend
Moongazer
Moongazer
Posts: 9
Joined: 2019-01-10, 09:22

Palemoon Portable components in low IO priority causing poor performance

Post by GogrillaMincefriend » 2020-06-02, 00:50

I'm not quite sure where this quirk originated, but when I was running a portable instance on a test box (airgapped Win 7 control machine, don't ask), I was experiencing very slow performance in a portable pale moon instance I had running from a (non-root) NVME drive. Just switching between two tabs might take a second or two despite being a very beefy machine.

Eventually, viewing Resource Monitor revealed that despite the drive (an enterprise 2TB M.2) being rated for a bare minimum of 16,000 write IOPS and 275,000 read IOPS, windows was seeing response times from the various components of the pale moon instance (xul.dll and places.sqlite being the main offenders) between 75 and 150ms, something you'd expect to see from a slow platter drive defragging in molasses on Europa.

Now, the NVME drive in question was under "load" at that point, semi-random reads at about 10-20MB/s but had plenty of spare bandwidth and IO. However, as it seems the processes are spawned in low IO priority, the windows IO scheduler seems loath to give them any IO at all even when there's plenty of spare capacity available and so even simple reads queue up behind every other higher priority request. Using the iopriority command line tool to bump pale moon back in to "normal" IO, regular performance was resumed. I suspect this perf problem might have been introduced in the 28.9.x series or thereabouts but I can't be sure as there was no reason to take measurements; the last time I looked at this box it was running one of the 28.8.x without obvious issues with the drive being under greater load.

At a guess I'd say that the low-IO priority is an effort to reduce the amount of thrashing when PM portable is run from slow USB devices and such, but aside from the IO scheduler being stupid, is there a way to disable the behaviour of opening PM portable in low IO priority mode (e.g. an option in the ini file) or is it solely a build-time thing and can't be turned off?
Attachments
low_prio.png

User avatar
therube
Board Warrior
Board Warrior
Posts: 1298
Joined: 2018-06-08, 17:02

Re: Palemoon Portable components in low IO priority causing poor performance

Post by therube » 2020-06-02, 01:19

Not that I know what I'm looking at, particularly, so I'll just throw it out there...

Running PM portable - from a HDD (yes, I know) - so don't know if that affects what's being seen.
Anyhow, appears that what I am seeing is I/O running at Normal priority.
(Again, maybe if run from Flash drive...?)
.
PaleMoon Disk IO running Normal.png
.
Win7, & I'm running in an Admin Level user account (in case that matters?).

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 27037
Joined: 2011-08-28, 17:27
Location: 58°2'16"N 14°58'31"E
Contact:

Re: Palemoon Portable components in low IO priority causing poor performance

Post by Moonchild » 2020-06-02, 01:28

The portable makes no special arrangements to change I/O scheduling at all; what you are seeing must therefore be the result of something else controlling the process properties.
"There will be times when the position you advocate, no matter how well framed and supported, will not be accepted by the public simply because you are who you are." -- Merrill Rose
Image

User avatar
GogrillaMincefriend
Moongazer
Moongazer
Posts: 9
Joined: 2019-01-10, 09:22

Re: Palemoon Portable components in low IO priority causing poor performance

Post by GogrillaMincefriend » 2020-06-02, 09:04

Thank you both for checking, I'll have a dig and see if I can find out why this happened.

I've just restarted the process as per usual and it's in normal IO priority now so I'm going to need to have words with anyone else who might have been fiddling with this. I figure that when the upgrade happened the originating PM process must have already been in low IO priority; the upgrade itself took an age, and I think when the upgrade restart occurred it spawned itself in the same IO class. I'll confirm that the next chance I have to upgrade.

Post Reply