Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: firefox (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1097989
Title:
Firefox poor memory management in live editions
Status in “firefox” package in Ubuntu:
Confirmed
Bug description:
This has been affecting my systems for some long time now, but it is not
immediately clear who should own the problem, between linux itself, the distro,
the Live concept, the filesystem used by Live editions, or firefox (as amended).
It is further complicated by the misbehaviour of Flash within its
plugin-container, which is not simply memory leakage but seems to get into lock
contention sometimes at quite low memory use.
I am of the view it's primarily a Firefox problem, because it is
Firefox that is allocating memory to itself, and it could be obviated
by altering the Firefox memory-grab allocation procedures - but there
is a relatively complex interaction.
Specifically, it has continued through to FF 16 in my certain experience, but
started ages ago.
The symptoms are similar to early & not well-formed bug/3677.
At one point I thought it was due to the aufs filesystem, but it continues
unabated.
It may exend to the installed system too, but I haven't actually
installed for some time.
Symptoms.
#######
I'm using a fairly capable recent laptop with over 3Gb enough of RAM.
There is an ample (and fast) HDD swap file.
Setting swappiness low does not seem to alter much.
Moving FF cache to disc does not make discernable difference.
The problem has affected other distros, but could well be solved here.
It occurs with a raw Firefox, no addons. In fact, it is worse without
extensions such as adblockplus & flashblock, which reduce consumed memory.
Using a live DVD edition for an extended time, after building up a number of
tabs with plenty of content, first Firefox, & then the whole system becomes
sluggish.
It goes on to have petit-mal seizures, ignoring all attempts of the actual
attendant computer-owner to intervene.
No reaction to mouse or keyboard. Very frustrating & time-wasting,
inefficient.
Sometime for many minutes, one cannot even get ctrl+alt+f1 to work, or to get
>top or >vmstat, or >free to display.
Occasionally, a hard "off" & start again, is the only solution.
This hïatus is accompanied by a great deal of clattering from the live
DVD, which seems to be going round in circles (the illogical process,
as well as the DVD). Such thrashing would be less apparent with a
silent system, installed HDD or flash drive, but I surmise that the
same inefficiency would be going on unheard, just that it would be
hidden, only manifesting as sluggishness.
Just to discount one set of objections:
Some might say that live editions are not for extended use. This is very true
with an improperly conditioned cows filesystem, since it fills up & locks
solid, with no way out. However, I see no reason why a live edition should not
be fully usable, if slightly slower. If anyone has a good non-bs argument
to the contrary, I have yet to hear it.
In some cases
>vmstat, when it can be invoked, shows a fair amount of out-swapping,
indicating some resource distress.
This is a clue.
In many cases, if there is an instance of plugin-container, to pkill it will
release resources & free up operations.
That's a slightly separate issue, but I do note that it is not simply a case
of memory leak un-freed allocation, since even at low plugin- memory levels,
the killing of plugin-container still causes release. In fact, it helps to kill
plugin-containe even if it is not visible at the head of >top.
Without much hard evidence, I suspect an interlock condition or resource
contention.
But this is a subset of the main problem.
What also seems to go on is that as time & usage goes on, Firefox tires &
gets more sluggish, almost as if it was written by Windows programmers. That
could be the effect of buggy websites, but FF should be resilient to that.
A restart seems to clear the decks. Use of about:memory to CC or GC has
little effect, indeed I've known CG to crash the instance of FF after a fair
locked-up wait. (More resource contention, and possibly a problem with
FF/kernel interfacing.)
A restart should not ideally be necessary.
What also seems to happen, is that unused web-page memory is not swapped out
as it might be, but seems to be locked in core. I'm not sure this is absolute.
This may have been done for security/privacy reasons, but it would be a great
help if such unused, un-focused memory were not taking up useful RAM.
SUGGESTION--> One might address the privacy/security problem, where swap is
allocated, by encrypting the swap.
Conjecture
+++++++++
We know that FF in its memory-hog incarnation grabs all the memory it can.
We hear this is "efficient use of resources", and not theft at all.
SUGGESTION(gripe)--> If it were polite, it would at least ~ask~ at
some stage; it might present the beleaguered actual owner of the RAM
with an option to limit its memory-grabbing ambitions, to allow the
user to decide how much resource to concede.
After all, we the user might wish to have some free memory spare to
load some other programmmes alongside, occasionally. Bleachbit, for
example. Or top. Or vmstat. Anything.
What I think is happening in the Live case is that FF is not computing the
correct measure of available RAM memory.
It is probably detecting that it is over-using RAM, so it packages up some
memory to put out of current RAM in to what it believes to be out-swap disc.
The problem then with a live edition, the out-swap "disc" is still in another
part of RAM, in a virtual filesystem.
Contention.
In addition, some parts of code may be being swapped out, but then
required, so the system goes inefficiently hunting on the DVD for the
live replacement. It would be interesting to put a monitor on the
seek.
If FF had its algorithms right I imagine it could get around this.
But there also need to be resource parameters set to allow relatively unused
parts of that pseudo out-swapped virtual filesystem to be properly swapped out
to the HDD swapfile.
It's a bit beyond my current expertise (years ago I could have managed it:).
I do hope someone here can look into this seriously, even if you
consider it to be an up-stream matter; otherwise I see the buck being
passed around for years to come (whilst Chromium takes over the
field).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1097989/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
