Author Topic: Are you marking FF 45.x XUL.DLL for high-mem load?  (Read 1596 times)

André Heldoorn

  • Sr. Member
  • ****
  • Thank You
  • -Given: 46
  • -Receive: 9
  • Posts: 276
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #15 on: July 14, 2017, 11:48:39 pm »
So do you mean attempting to do that video_downloader install immelidately triggered the 100% cpu load? Or was it that AFTER the install the load started?

None of the above. Pressing <CTRL-O> to open the file dialog, to be able to select the third *.XPI file to be installed, triggered the CPU load of 100% without a responsive system. As described, pressing <CTRL-O> to trigger the problem after having installed two *.XPI files has nothing to do with what the third *.XPI file is, nor with an assumed generic problem. The FF beta displays the file dialog, the CPU load becomes 100%, the system isn't responsive anymore, and CAD is the way out.

Phase 3 of the decribed problem with an old profile: a 100% CPU load for a long while, FF is usable for a while, and finally a 100% CPU load without a responsive system.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 94
  • Posts: 1125
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #16 on: July 15, 2017, 02:09:11 am »
The only 100% loads I've seen here are from np binary plugins triggering plugin-container.exe to go into 100% load, which is now fixed. I'm using no-script but not adblock, instead I have privoxy installed though lately not using it. Just with no-script I pretty well see no ads, important on dial-up. I'd suggest checking out privoxy, privoxy.org IIRC, native, not built with GCC so none of the weird resource leaks.
Seems to me I gave up on video download helper some releases back as it was causing problems.
Anyways hopefully they'll be a new release soon, once the newest nspr and libcx work their way through the RPM process.

André Heldoorn

  • Sr. Member
  • ****
  • Thank You
  • -Given: 46
  • -Receive: 9
  • Posts: 276
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #17 on: July 15, 2017, 09:32:37 am »
I'm using no-script but not adblock, instead I have privoxy installed though lately not using it. Just with no-script I pretty well see no ads, important on dial-up.

I'll survive without adblock, but adblock XOR noscript doesn't trigger phase 3. ablock AND noscript cause a significantly higher CPU load during phase 1, loading FF. adblock AND noscript AND a clean start of FF (like no add-on welcome pages anymore) AND any trigger (this time: just pressing <CTRL-O>) caused the fatal phase 3.

Add-on used are random. I avoided obscure add-ons like a specific langpack or dictionary. I could have tried to open x:\AUTOEXEC.BAT instead of the video-one. The number of add-ons may play a role, based on nothing but the exponential CPU usage growth during phase 1.

The video-one stopped working with the previous version of SM, and I'm not using any of the registered-only, multi-core HD formats.

Well, It's still a beta. I don't know nor really care if such a bug was reported (FF bug or add-on bug).

For a next full version of FF I'm hoping for the last single-core main version (48?) of FF, because of the average age of OS/2 hardware. Multi-core hardware is not always an option, unless I'd really want to compile my own eCS 1.2RR installable CD.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 94
  • Posts: 1125
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #18 on: July 16, 2017, 01:47:50 am »
The other option for a replacement of adblock is ublock origin, much lighter and doesn't get paid to allow some ads.
The extensions ecosystem is always somewhat buggy, as it gives pretty low level access to the guts of the browser, which is why they're going away in a few months and also why he first thing people are told when reporting bugs is to try a new profile.

I really don't know what you mean by
Quote
For a next full version of FF I'm hoping for the last single-core main version (48?) of FF, because of the average age of OS/2 hardware. Multi-core hardware is not always an option, unless I'd really want to compile my own eCS 1.2RR installable CD.
or
Quote
and I'm not using any of the registered-only, multi-core HD formats.

As there is no such thing as multi-core HD formats or any dependency on multi-cores with Mozilla. Some video encoders/decoders will take advantage of multi-cores as well as various SIMD instructions, likewise with Mozilla, it's multi-threaded and more stuff is being moved off the main thread but OS/2 has always been multi-threaded, handles multiple threads well with one core and will keep working. Likewise the JavaScript JIT will probe your CPU capabilities and use the relevant instructions. Other parts of Mozilla are becoming dependent on SSE2 so older CPU's will stop working.
Eventually the show stopper will be the limited address space that 32bit CPU's give.

Daniel Carroll

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 22
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #19 on: July 16, 2017, 05:26:15 am »
I use a HOSTS file from http://winhelp2002.mvps.org/hosts.htm to block ads and such.

This is just a text file that points bad sites to never-never land. The actual file used is the 484 kb file marked "To view HOSTS in plain text form." found a few lines below the red text. You can also download the .zip file, which in addition has a loader and info for various versions of Windows.

If the file x:\mptn\etc\hosts (where x is your boot partition) has only one line in it: "127.0.0.1                 localhost", then copy hosts to hosts.bak and replace hosts with the downloaded hosts file. If you added lines to hosts, add them to the new hosts file.

I hope someone finds this useful.

André Heldoorn

  • Sr. Member
  • ****
  • Thank You
  • -Given: 46
  • -Receive: 9
  • Posts: 276
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #20 on: July 16, 2017, 10:50:44 am »
Here disabling adblock_plus-2.8.2-an+fx+sm+tb.xpi helps. No more long-lasting initial CPU load of 100% during the last phase of starting FF, and so far the system remains responsive. Disabling another randomly selected add-on doesn't help. There may be some conflict, because IIRC just installing Adblock Plus helped too. I've not checked possible known Adblock Plus bugs nor reported FF bugs, and YMMV.

André Heldoorn

  • Sr. Member
  • ****
  • Thank You
  • -Given: 46
  • -Receive: 9
  • Posts: 276
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #21 on: July 16, 2017, 12:23:59 pm »
Disabling Adblock Plus does not work with SM 2.42. Safe Mode works.

Dariusz Piatkowski

  • Full Member
  • ***
  • Thank You
  • -Given: 9
  • -Receive: 8
  • Posts: 249
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #22 on: July 16, 2017, 07:17:05 pm »
Dave & Daniel,

I have been using both Privoxy (for years) and the modified HOSTS file (for about a year) now. Both helped with the privacy as well as actual amount of data traffic aspects.

The times I'm seeing CPU spikes on my system, like right now for example, I'm not even refreshing a page. FF is literally in a 'quiet' mode as I'm typing up this thread response, yet the spikes continue...see the real-time (as I type this) result of the CPU monitor.

André Heldoorn

  • Sr. Member
  • ****
  • Thank You
  • -Given: 46
  • -Receive: 9
  • Posts: 276
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #23 on: July 16, 2017, 11:06:37 pm »
right now for example, I'm not even refreshing a page

Same here, again, but with a far slower Pentium 4 CPU. During the most recent FF test <CTRL-O> triggered phase 3, but typically phase 3 will start after a while, while doing nothing with about:blank. Did you ever report that --safe-mode "works" for you too?

If you're actually using this product, then you could consider to report a FF bug. It's probably a generic bug of a beta release, which is not related to a specific add-on. SM 2.42 remains unusable, even with a disabled Adclock Plus. It may even be a know bug.

Dariusz Piatkowski

  • Full Member
  • ***
  • Thank You
  • -Given: 9
  • -Receive: 8
  • Posts: 249
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #24 on: July 17, 2017, 04:49:14 pm »
1st progress update...

...My approach is to have created a NEW profile, where one by one I will add the extensions to get me back to the current level...Will update this thread with the results as I discover things!

Alright, so I slightly altered my approach. Instead of just starting by installing the add-ons I decided to try to replicate everything but the add-ons themselves, so literaly bringing my bookmarks, history, etc etc...all the "soft" stuff. The change was driven by the fact that having a clean-slate profile really did not allow me at all to use the browser in it's entirety, as if it was my FULL setup...therefore, a like-to-like testing really could not be done.

To do this I followed this https://support.mozilla.org/en-US/kb/recovering-important-data-from-an-old-profile, which I think does a pretty good job of covering everything.

Drummroooolllll......unfortunately with NO add-ons installed, I am back to the same place I started with, namely, the CPU spikes continue.

So my next step is to now remove these individual profile migration files and see if there is any impact, although at this point in time I am suspecting that what I'm seeing may simply be inherent to our OS/2 platform, or perhaps more specificly to a given combination of installs and therefore the underlying components on a particular OS/2 machine.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 94
  • Posts: 1125
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #25 on: July 17, 2017, 06:20:19 pm »
Have you tried temporarily disabling more cores? Perhaps try just using one or two.

André Heldoorn

  • Sr. Member
  • ****
  • Thank You
  • -Given: 46
  • -Receive: 9
  • Posts: 276
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #26 on: July 17, 2017, 08:17:25 pm »
Pentium 4 CPU, "phase 1", same x-axis and y-axis scales:

--safe-mode.png: full--safe-mode Safe Mode launch procedure
no-adblock.png: full -browser launch procedure with several add-ons, Adblock Plus is disabled
enabled-adblock.png: full -browser launch procedure with all add-ons, Adblock Plus is enabled

I guess the differences are too clear to not be noticed. During the next phase FF can be used. Phase 3, not included, looks like a lasting 100% CPU load and a system which isn't responsive anymore.

Dariusz Piatkowski

  • Full Member
  • ***
  • Thank You
  • -Given: 9
  • -Receive: 8
  • Posts: 249
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #27 on: July 17, 2017, 08:38:26 pm »
Dave,

Have you tried temporarily disabling more cores? Perhaps try just using one or two.

No!!! I did not try this approach, I was bouncing between 5 cores or a single core. Soo...curious, shutting off all but 1 core and then slowly bringing them back on-line shows interesting behaviour. The spikes continue, but they go from a nearly full (100%) cpu load, as in the case of a single core, to a more evently distributed spikes across multiple cores. TOP shows FF as having 100% cpu load at all times though, but the method TOP uses is NOT intended to measure CPU load, instead it compares a TOTAL amount of CPU time in the previous measuring cycle and compares that to the particulars of the current cycle. So it's basically an on-going comparison of how the workload is being moved around from core to core and from process to process.

So I moved to the IBM supplied 'SMP Monitor' next. Here I set the refresh rate to 100ms, which gives a nearly real-time view of what's going on - lol, well as best as a human eye is concerned anyways, any quicker than that and I can not keep up with it!!!

As could be expected all the 5 cores continuously spike between idle and 100. The average in this case is probably more telling as it shows continuous fluctuation between 30-80%. I would say that is consisten with what 'CPU Monitor' shows with it's average over previous 1 minute calculation.

Disabling all but two cores produced the attached CPU utilization graph. TOP shows FF as the application with 100% utilization.



Dariusz Piatkowski

  • Full Member
  • ***
  • Thank You
  • -Given: 9
  • -Receive: 8
  • Posts: 249
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #28 on: July 21, 2017, 06:32:48 pm »
2nd progress update...

...So my next step is to now remove these individual profile migration files and see if there is any impact, although at this point in time I am suspecting that what I'm seeing may simply be inherent to our OS/2 platform, or perhaps more specificly to a given combination of installs and therefore the underlying components on a particular OS/2 machine.

Hmm...a bit of a weird situation...LOL. I continued on with my testing but the browser would sometimes go into these crazy CPU spikes and other times it would simply just DROP-OFF entirely and stay quiet. I could not really establish a pattern other than the obvious "...ohh, there it is again..." moment!

Further on, I decided to clean up the profile data first by removing various left-over settings from prefs.js file. I had a bunch of old stuff such as printer entries for printer that no longer exist and other changes I have tried over the years...so some clean-up was required either way.

Once I completed this I then felt I needed to re-install (from scratch) all my current add-ons in the new profile AND set these up to be exactly the same as my old profile. That took a while to do, but I think I was able to replicate this setup.

In the end, the new profile really has the behaviour of my old one, but hopefully none of the "baggage".

So what am I seeing now?

Well, here are some findings:

1) the browser is more stable for a longer period of time
2) the CPU spike seems to be related to how much memory FF is currently using, on my machine with the VIRTUALADDRESSLIMIT=2560 setting I find that FF start going "crazy" right around the time Theseus shows 1Gig of memory usage
3) as FF slows down the spikes still occur but this time they are actually much smaller, meaning that I am not seeing the full 100% peg and a non-responsive browser, this I will continue to evaluate since I do not have enough usage cycles gathered yet to really narrow this down further

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 94
  • Posts: 1125
    • View Profile
Re: Are you marking FF 45.x XUL.DLL for high-mem load?
« Reply #29 on: July 22, 2017, 04:17:30 am »
Something seems to have changed here, perhaps the last NSPR update (have to test on a different un-updated system) as I'm seeing more CPU usage when the browser (and TB) are idling. One core are 10-20% and the second at 15-30% and higher when scrolling, loading a page etc.