Firefox Ram Auslastung sehr hoch

duAffentier

Admiral
Registriert
Jan. 2008
Beiträge
7.343
Hallo,

mein FF in der Aktuellen Version bzw. die davor auch, haben nach einer gewissen Zeit eine Rambelegung von ca 1GB. Ist dies den normal?
Hab meist 2-5 Tabs offen.
Teilweise Flash seiten, aber eher selten! Meist nur FB oder CB, Browser Games.
Ist es den da üblich, das Firefox dann immer mehr Ram belegt. Derzeit ist es 500MB. Wird aber mit der Zeit mehr.
Woran liegt den dies?

Lg
 
FF war schon immer sehr RAM-hungrig.

Habe gerade 2 Tabs offen (Facebook & CB) und 200MB (220.164k) werden dafür gebraucht.

Zudem kommen noch Add-Ons, Plug-Ins und solche Spielerein die du nicht vergessen darfst.
 
Zuletzt bearbeitet:
Du musst about:memory aufrufen und schauen wo der Fireox RAM schluckt. Meiner belegt 180MB.
 
So sieht dies aus dann!
Sagt dir das etwas?!
Main Process

Explicit Allocations
405.55 MB (100.0%) -- explicit
├──147.72 MB (36.42%) ++ js-non-window
├──124.83 MB (30.78%) ++ window-objects
├───99.94 MB (24.64%) ── heap-unclassified
├───16.21 MB (04.00%) ++ storage
├───12.52 MB (03.09%) ++ (11 tiny)
└────4.34 MB (01.07%) ── network-memory-cache

Other Measurements
297 (100.0%) ++ js-compartments

253.30 MB (100.0%) ++ js-main-runtime

106.43 MB (100.0%) ++ js-main-runtime-gc-heap-committed

0 (100.0%) ++ low-memory-events

19.25 MB (100.0%) ++ window-objects

0.96 MB ── canvas-2d-pixel-bytes
407.93 MB ── explicit
3.95 MB ── gfx-d2d-surfacecache
20.04 MB ── gfx-d2d-surfacevram
0.96 MB ── gfx-d2d-vram-drawtarget
0.00 MB ── gfx-d2d-vram-sourcesurface
4.40 MB ── gfx-surface-image
0 ── ghost-windows
260.70 MB ── heap-allocated
297.23 MB ── heap-committed
36.52 MB ── heap-committed-unused
14.00% ── heap-committed-unused-ratio
3.17 MB ── heap-dirty
179.30 MB ── heap-unused
0.82 MB ── images-content-used-uncompressed
139.00 MB ── js-gc-heap
0 ── low-commit-space-events
530.92 MB ── private
547.64 MB ── resident
0.00 MB ── shmem-allocated
0.00 MB ── shmem-mapped
15.41 MB ── storage-sqlite
1,091.11 MB ── vsize
 
Ein weiterer Faktor kann sein, dass sich Firefox bereits geschlossene Tabs im Ram merkt - die kannst Du mit Strg+Shift+T wiederherstellen.

Standardmäßig merkt er sich 10. Das kann mit "about:config" unter der Einstellung "browser.sessionstore.max_tabs_undo" aber auch jederzeit ändern.

1,091.11 MB ── vsize

Die letzte Zeile sagt alles - er hat 1 GB virtuell reserviert.

Da hat der Browser wohl zwischenzeitlich mal 1 GB gebraucht - braucht aber zur Zeit aber nur ca. 450 MB.

Den Speicher hat wohl nicht zurückgegeben, da Du wahrscheinlich ausreichend ungenutzten Hauptspeicher hast...
 
Zuletzt bearbeitet: (erweitert)
Das Problem hat unterschiedliche Ursachen , ich hab auch bis zu 10 unterschiedliche Tabs auf und lasse den Browser bis zu 12h laufen und aktualisiere dabei nur einzelne Tabs wie zb. Foren.
Dabei habe ich noch 14 Firefox Addons installiert.

Firefox macht jetzt 2 Dinge , je mehr Addons installiert sind umso mehr bläht er sich auf und der Firefox speichert den gesamten Browsingverlauf und gibt ihm nichtmehr frei (siehe Bild) , auch nicht beim Schliessen von 9 von 10 Tabs.

firefox_1700mb-jpg.303681
 
Kommt auf die Seiten an die Du offen hast. Wenn Du z.b. Bildportale besuchst, die Dir 1000e von Bildern in den Browser kopieren, dann braucht der natürlich seinen Speicher. Nur so für den Hinterkopf.
 
Das Problem liegt an einigen Add-ons oder Plugins. Selbst mit meinem 64bit Firefox komme ich selten über 4-600MB.

Hier mein 64bit Firefox mit 14 Add-ons und 8 tabs.
 
Zuletzt bearbeitet:
ich_nicht schrieb:
Ich würde dir einen zurechtgekürtzten Chrome emphelen. Dort lassen sich meiner Meinung nach die addons und Plugins sehr gut veralten. Und technisch soll es auch einer der besten sein.

Ähm... ne. Der Speicherverbrauch bei Chrome funktioniert nur grundsätzlich anders als bei FF.

FF: Alle Tabs, Addons etc. laufen in einem Prozess und teilen sich einen Speicherbereich. Der FF hat Probleme, bei geschlossenen Tabs ungenutzten Speicher wieder freizugeben. Es kommt bei längerer Nutzung zur Fragmentierung. Browser aus- und wieder anschalten hilft.

Chrome: Jeder Tab und jedes Addon bilden einen eigenen Prozess mit eigenem Speicherbereich. Ein zusätzlicher Prozess ist die eigentliche GUI nebst Render-Engine. Wird ein Tab geschlossen gibt er seinen Speicher sofort wieder frei. Andererseits belegt die Vielzahl an Prozessen auch viel mehr RAM durch den höheren Verwaltungsaufwand.

Je mehr Tabs und Addons man nutzt, desto mehr gewinnt FF das RAM-Rennen, zumindest wenn man ihn mal alle paar Stunden komplett zu macht um den gesamten Speicher frei zu geben und neu zuzuweisen.
Dafür schmiert bei Chrome nicht der ganze Browser ab, nur weil ein Addon oder Tab krepiert. Hat alles Vor- und Nachteile. Da RAM aber quasi der Pfennig-Artikel unter der PC-Hardware ist: scheiß drauf, soll sich der Browser halt 2GB nehmen.
 
Die Anzahl der Tabs sagt nichts über die Speicherbelegung.
Hier z.B. nur ein einziger Tab ist geöffnet.
 
MagicAndre1981 schrieb:
klappe die js-non-window und window-objects Einträge mal weiter auf.

Hier ist es :)
Code:
Explicit Allocations
399.20 MB (100.0%) -- explicit
├──147.55 MB (36.96%) -- js-non-window
│  ├──105.32 MB (26.38%) -- compartments
│  │  ├───86.47 MB (21.66%) -- non-window-global
│  │  │   ├──32.94 MB (08.25%) -- compartment([System Principal], file:///C:/Users/Home/AppData/Roaming/Mozilla/Firefox/Profiles/kmdteo40.default/extensions/firefox@ghostery.com/components/ghostery-content-policy.js)
│  │  │   │  ├──14.27 MB (03.58%) -- gc-heap
│  │  │   │  │  ├───6.85 MB (01.72%) ── strings
│  │  │   │  │  ├───4.04 MB (01.01%) ++ objects
│  │  │   │  │  └───3.38 MB (00.85%) ++ (5 tiny)
│  │  │   │  ├──12.71 MB (03.18%) ── string-chars
│  │  │   │  ├───5.57 MB (01.39%) -- objects
│  │  │   │  │   ├──5.53 MB (01.38%) ── slots
│  │  │   │  │   └──0.04 MB (00.01%) ── elements
│  │  │   │  └───0.38 MB (00.10%) ++ (4 tiny)
│  │  │   ├──32.27 MB (08.08%) ++ (256 tiny)
│  │  │   └──21.26 MB (05.33%) -- compartment([System Principal], jar:file:///C:/Users/Home/AppData/Roaming/Mozilla/Firefox/Profiles/kmdteo40.default/extensions/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D.xpi!/bootstrap.js (from: resource:///modules/XPIProvider.jsm:3595))
│  │  │      ├──15.08 MB (03.78%) -- gc-heap
│  │  │      │  ├───7.81 MB (01.96%) ++ (6 tiny)
│  │  │      │  └───7.27 MB (01.82%) ── unused-gc-things
│  │  │      └───6.18 MB (01.55%) ++ (7 tiny)
│  │  └───18.85 MB (04.72%) -- no-global
│  │      ├──18.85 MB (04.72%) -- compartment(atoms)
│  │      │  ├──15.14 MB (03.79%) ── string-chars
│  │      │  └───3.71 MB (00.93%) ++ (2 tiny)
│  │      └───0.00 MB (00.00%) ── compartment(https://www.computerbase.de/forum/usercp.php, about:blank)/other-sundries
│  ├───36.84 MB (09.23%) -- gc-heap
│  │   ├──34.67 MB (08.68%) ── decommitted-arenas
│  │   └───2.17 MB (00.54%) ++ (3 tiny)
│  └────5.39 MB (01.35%) -- runtime
│       ├──4.00 MB (01.00%) ── atoms-table
│       └──1.39 MB (00.35%) ++ (12 tiny)
├──112.74 MB (28.24%) -- window-objects
│  ├───50.19 MB (12.57%) -- top(none)/detached
│  │   ├──48.57 MB (12.17%) -- window([system])
│  │   │  ├──48.56 MB (12.16%) -- js
│  │   │  │  ├──43.92 MB (11.00%) -- compartment([System Principal], chrome://browser/content/browser.xul)
│  │   │  │  │  ├──24.18 MB (06.06%) -- gc-heap
│  │   │  │  │  │  ├───9.29 MB (02.33%) ── unused-gc-things [7]
│  │   │  │  │  │  ├───5.57 MB (01.40%) ++ (4 tiny)
│  │   │  │  │  │  ├───5.27 MB (01.32%) ++ objects
│  │   │  │  │  │  └───4.06 MB (01.02%) ++ shapes
│  │   │  │  │  ├──11.87 MB (02.97%) ── script-data [7]
│  │   │  │  │  └───7.87 MB (01.97%) ++ (5 tiny)
│  │   │  │  └───4.64 MB (01.16%) ++ (2 tiny)
│  │   │  └───0.01 MB (00.00%) ── dom/other [17]
│  │   └───1.62 MB (00.41%) ++ window(https://www.computerbase.de/forum/threads/windows-8-vier-millionen-upgrades-in-vier-tagen.1129112/)
│  ├───40.37 MB (10.11%) -- top(chrome://browser/content/browser.xul, id=3)/active
│  │   ├──40.33 MB (10.10%) -- window(chrome://browser/content/browser.xul)
│  │   │  ├──38.20 MB (09.57%) -- js/compartment([System Principal], about:blank)
│  │   │  │  ├──18.41 MB (04.61%) -- gc-heap
│  │   │  │  │  ├───9.83 MB (02.46%) ++ (6 tiny)
│  │   │  │  │  └───8.58 MB (02.15%) -- objects
│  │   │  │  │      ├──8.15 MB (02.04%) ── non-function
│  │   │  │  │      └──0.43 MB (00.11%) ── function
│  │   │  │  ├───7.33 MB (01.84%) ── string-chars
│  │   │  │  ├───4.32 MB (01.08%) ++ objects
│  │   │  │  ├───4.15 MB (01.04%) ++ (6 tiny)
│  │   │  │  └───4.00 MB (01.00%) ── cross-compartment-wrappers
│  │   │  └───2.13 MB (00.53%) ++ (4 tiny)
│  │   └───0.04 MB (00.01%) ++ window(about:blank)
│  ├───13.50 MB (03.38%) -- top(https://www.computerbase.de/forum/threads/firefox-ram-auslastung-sehr-hoch.1131058/, id=3803)
│  │   ├───7.40 MB (01.85%) -- active
│  │   │   ├──4.10 MB (01.03%) ++ window(https://www.computerbase.de/forum/threads/firefox-ram-auslastung-sehr-hoch.1131058/)
│  │   │   └──3.30 MB (00.83%) ++ (3 tiny)
│  │   └───6.11 MB (01.53%) ++ cached/window(https://www.google.de/search?q=firefox+ram+auslastung&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:de:official&client=firefox-a#q=firefox+ram+auslastung&hl=de&client=firefox-a&tbo=1&rls=org.mozilla:de:official&prmd=imvns&source=lnt&tbs=qdr:y&sa=X&ei=7lGWUMeuDMbusgbYpoHIBA&ved=0CCAQpwUoBQ&bav=on.2,or.r_gc.r_pw.r_qf.&fp=cf8597037e31cd2a&bpcl=37189454&biw=1662&bih=844)
│  ├────6.92 MB (01.73%) ++ top(http://www.willstequatschen.de, id=8)/active
│  └────1.76 MB (00.44%) ++ (4 tiny)
├──102.14 MB (25.59%) ── heap-unclassified
├───17.26 MB (04.32%) ++ storage
├───10.56 MB (02.65%) ++ (10 tiny)
├────4.60 MB (01.15%) -- images
│    ├──4.29 MB (01.07%) -- content
│    │  ├──4.29 MB (01.07%) ++ used
│    │  └──0.00 MB (00.00%) ++ unused
│    └──0.31 MB (00.08%) ++ chrome
└────4.34 MB (01.09%) ── network-memory-cache


Kann man den FF auch sagen, gebe Speicher wieder Frei?!
 
FF gibt Speicher wieder frei, wenn er ihn nicht mehr benötigt. Aufgrund des Single-Process-Designs kann er aber nicht alles freigeben. Es kommt früher oder später zu Fragmentierungseffekten.
 
Eher nicht. Das Problem liegt am Design mit einem Prozess für alles. Wenn FF ein Multi-Prozess-Modell wie Chrome verwenden würde, würde der Speicher dynamischer auf Anforderungen reagieren.
 
@uAffentier

ghostery deinstalliere und über geringerer RAM Nutzung freuen.
 
Zurück
Oben