Tristan Nitot nous explique sur son blog [1] comment firefox 1.5 utilise la mémoire pour son système de cache des pages consultées (ou bfcache pour les intimes).
En gros, on y apprend que Firefox utilise la mémoire s'il y en a, et donc prends ses aises. Le système bfcache permet de prendre une photo des pages consultées pour les réafficher très rapidement.
Vous trouverez plus d'explication sur le web de pascal [2]. On y apprend alors que le nombre de photos stockées en mémoire dépend de la mémoire disponible sur le PC. Et qu'il est également possible de modifier ce nombre de photos (via about:config). Un cliché fait 4Mo en moyenne, et le nombre de cliché dépend également du nombre d'onglet. En gros, si votre firefox est configuré pour garder 2 clichés par pages (stocke donc en mémoire les 2 dernières pages consultées), alors vous devez multiplier ce nombre par le nombre d'onglet ouvert.
[1] http://standblog.org/blog/2006/01/10/93114599-occupation-mem(...)
[2] http://www.chevrel.org/fr/carnet/index.php?2006/01/05/545-pa(...)
Journal Gestion de la mémoire sous Firefox 1.5
10
jan.
2006
# Mouais
Posté par Zenitram (site web personnel) . Évalué à 9.
D'après ce que dit T. Nitot, FF ne verifie jamais qu'on en veut maintenant de la memoire a un instant t+1, donc c'est galere, faut le fermer de temps en temps pour "reinitialiser" son algorithme...
J'espere que FF fait des tests parfois, mais j'ai des doutes :)
[^] # Re: Mouais
Posté par Sixel . Évalué à 5.
Je le démarre toujours avec 7 onglets ouverts, donc 3 se rechargent toutes les minutes (des webmails) et DLFP sur lequel je navigue pas mal durant la journée. Compter en plus de cela toute un floppée d'onglets issus de recherches Google, je suis quasiment chaque jour avec minimum une 15aine d'onglets ouverts quand je pars du taf. Et la conso de mémoire ne dépasse jamais les 60Mo!
Et les autres applis lancées (généralement Eclipse, TOAD, IE et TeXnicCenter, toutes en même temps) ne souffrent jamais...
/me, très satisfait de son FF qui ne lui bouffe "que" 60 de ses 512 Mo de mémoire...
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
[^] # Re: Mouais
Posté par Colin Pitrat (site web personnel) . Évalué à 7.
[^] # Re: Mouais
Posté par Yth (Mastodon) . Évalué à 5.
Ca, ça force à fermer firefox :(
Yth.
[^] # Re: Mouais
Posté par Gmooron . Évalué à 3.
[^] # Re: Mouais
Posté par nicoprog . Évalué à 3.
Par contre avec un ou deux onglets d'ouverts qui ont du flash à l'interrieur j'arrive souvent vers les 110-120Mo :(
Conclusion : Je ne visite pas couramment les sites où il y a du Flash.
[^] # Re: Mouais
Posté par Mathieu Pillard (site web personnel) . Évalué à 9.
Un bon billet d'un développeur mozilla sur comment faire des bon bug reports concernant tous les problemes de memory leak: http://dbaron.org/log/2006-01#e20060110a
A lire absolumment. Certains tendent amha à oublier que firefox est libre: ca n'excuse peut etre pas ses bugs, mais cela n'empeche pas que vous pouvez contribuer, en prenant du temps pour reporter des bugs les plus complets possibles, en essayant de trouver quels sites posent probleme a firefox (voire meme pourquoi), etc. Meme sans renter dans les contributions au code en lui meme, il ya beaucoup à faire, et c'est AMHA bien plus gratifiant et interessant que de troller ici sur le sujet à longueur de journée.
[^] # Re: Mouais
Posté par Gniarf . Évalué à 3.
[^] # Re: Mouais
Posté par psychoslave__ (site web personnel) . Évalué à -3.
[^] # Re: Mouais
Posté par gc (site web personnel) . Évalué à 10.
[^] # Re: Mouais
Posté par Nicolas S. . Évalué à 2.
Mais bon je ne serai pas contre la possibilité de mettre une limite haute dans firefox.
[^] # Re: Mouais
Posté par lolop (site web personnel) . Évalué à 2.
http://www.google.fr/search?q=firefox+limit+memory+usage
Et hop:
http://forums.mozillazine.org/viewtopic.php?t=172041
http://discuss.extremetech.com/forums/3/1004292531/ShowPost.(...)
http://fusion94.org/archives/2005/07/firefox_memory.html
Faut-il traduire ?
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Mouais
Posté par TImaniac (site web personnel) . Évalué à 2.
Que FF se mette à l'aise dans la mémoire quand il y en a OK, mais il faudrait qu'il s'adapte en cours de route plutôt que d'être obligé de le limiter.
[^] # Re: Mouais
Posté par lolop (site web personnel) . Évalué à 2.
Mais là je ne répond pas à Mme Michu, mais à Nicolas Salles, dans un journal sur LinuxFR. J'imagine qu'il connaît un peu google et peut se débrouiller avec 7 lignes d'anglais.
Sinon, quand tu parles d'adaptation...
Lorsque tu fait un malloc, ton appli récupère un bloc que la librairie C a demandé au système. Par contre quand tu fait un free, tu libères le bloc au niveau de la librairie C... mais pas au niveau de l'OS et de la mémoire virtuelle. Faudrais descendre plus bas vers les appels système de gestion du heap & Co.
Comment savoir à quel moment il est censé libérer la mémoire (qui décide qu'une appli est plus prioritaire qu'une autre pour ce qui concerne l'utilisation mémoire ?). Ce genre de choses devait être dispo sur les OS des gros systèmes (genre MVS et VMS) dans des worksets, et ça doit encore se retrouver dans certains Unix proprios... qq'un connait ?
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Mouais
Posté par TImaniac (site web personnel) . Évalué à 1.
garbage collector.
Le programme indique qu'un objet est "libérable" (weak reference dans les langages de haut niveau), dans notre exemple une page web sauvegardé.
L'OS prévient le garbage collector quand il a besoin de ressources. Le GC libère l'espace dont il n'a plus besoin (objets plus accessibles), et les objets libérables.
Le programme test (référence null dans un langage de haut niveau) si l'objet existe au moment d'y accéder :
if(obj == null)//plus dans le cache, le GC la libéré parcque besoin de mémoire
obj = new ...
else //dans le cache
Normalement si le GC est bien foutu, il va éviter de libérer systématiquement la mémoire des objets libérables (puisqu'il pourra potentiellement les recycler, et parcque c'est pas nécessaire, ca sert à rien de bouffer du CPU), on va donc avoir un cache qui va grossir, et qui va se "vider" lorsque l'OS aura besoin de mémoire.
Evidemment, quand on programme encore en C avec des malloc et des free c'est une autre pair de manche :)
[^] # Re: Mouais
Posté par Gniarf . Évalué à 7.
vraiment ?
[^] # Re: Mouais
Posté par TImaniac (site web personnel) . Évalué à 2.
- "désolé je peux plus t'allouer de mémoire" (comprendre ca sature)
- "va en arrière-plan" (comprendre t'es pas prioritaire, y'a d'autres applis qui ont besoin de ressources)
- "endors toi" (comprendre qu'on s'occupe pas de toi)
On peut aussi imaginer que le GC vérifie la quantité de mémoire disponible de temps en temps et s'assure d'en garder en permanence un certain pourcentage.
[^] # Re: Mouais
Posté par lolop (site web personnel) . Évalué à 2.
C'est que pour le moment les OS communs (Windows, Linux) ne fonctionnent pas comme ça.
Y'a aussi que ça n'est pas si simple (fragmentation, taille des pages vs taille des blocs alloués par le programme...).
Dans le genre réclamation mémoire, il y avait la gestion des handlers sur Macintosh (pré-MacOSX), où tu pouvait indiquer un handler mémoire comme purgeable, et à ce moment l'OS pouvait le libérer s'il était un peu court en mémoire - comme tu l'indiques. Bon, c'est vrai que toutes les applis se partagaient la mémoire... et qu'il n'y avait pas de swap, pagination & Co.
Et pour malloc et free... ça fait quand même pas mal d'applications qui sont basées dessus.
Q? Sous linux y'a pas moyen de lui coller un ulimit juste pour le process firefox ?
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Mouais
Posté par TImaniac (site web personnel) . Évalué à 2.
Pas les OS, mais les machines virtuelles associés à un GC oui. Utiliser le GC pour faire un cache qui s'adapte à la taille de la mémoire c'est un pattern courant. Mais tu peux très bien le simuler en C/C++, il me semble que c'est plus ou moins ce que fait Apache par exemple.
[^] # Re: Mouais
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: Mouais
Posté par Thomas Douillard . Évalué à 1.
[^] # Re: Mouais
Posté par Zenitram (site web personnel) . Évalué à 2.
Si on suis ton analogie, autant prendre Windows comme OS et IE comme navigateur : en effet, comme il y a l'antivirus derrire pour faire le ménage, pas la peine de prendre des choses plus sécurisés.
Comme tu es ici, je suppose que tu prefere utiliser Linux et FF (ou autre) pour ta sécurité/fiabilité, je suis surpris que tu ne souhaite pas faire la meme chose pour la programmation (qui est la base du systeme fiable que tu utilise, c'est en C sans GC...)
[^] # Re: Mouais
Posté par TImaniac (site web personnel) . Évalué à 1.
On peut aussi se dire :
On a envi d'avoir un programme pas buggué, et laisser ce boulot trop délicat qu'est la gestion mémoire a des algorithmes connus et bien implémenter.
Mais bon on sort du sujet. Moi je voulais juste dire que si un GC est capable de faire un cache adaptatif, Firefox doit être capable de le faire, même sans GC.
[^] # Re: Mouais
Posté par Thomas Douillard . Évalué à 2.
Je vois pas trop le rapport entre le libre et le garbage collecting. Avec l'antivirus non plus.
Si un outil permet une bonne gestion de la mémoire sans que le programmeur se prenne la tête et à de bonnes performances, le tout en se prenant moins la tête sur les bugs de mémoire, pourquoi pas ?
Cela dit, il peut quand même y avoir des problèmes de mémoire avec un gc, des fuites, des pointeurs NULL, etc.
Mais franchement, je ne vois le rapport ni avec la sécurité (qui pourrait être augmentée, en supprimant quelques problèmes de mémoires, donc quelques failles), ni avec un antivirus. Qui plus est, je suis pas dupe du fait que linux n'est pas théoriquement à l'abris des virus, plus sécurisé ou pas que windows, un virus qui tourne avec les privilèges d'un utilisateur et qui fait beaucoup de dégats, ca n'a pas grand chose d'impossible.
Bon, trève de troll, on sort effectivement pas mal du sujet.
[^] # Re: Mouais
Posté par Nicolas S. . Évalué à 1.
Sur le coup, je découvrais l'explication de l'utilisation de la mémoire par firefox et je n'avais pas encore pris le temps de chercher.
J'aurai pu modérer davantage mes mots.
[^] # Re: Mouais
Posté par Gmooron . Évalué à 3.
Il ya un bug typique dans fx avec les addEventListener qui doivent etre enleves par les concepteurs des extensions eux-memes ....
[^] # Re: Mouais
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
Il yen a d'autres, mais celui la peut etre dévastateur avec plein d'images JPEG. Si tu veux faire avancer les choses, tu peux surveiller ton firefox avec xrestop, pmap, etc, et commenter/rapporter des bugs.
# Konqui
Posté par TNorth . Évalué à 6.
J'aime bien FF pour ses extensions, mais sur une petite machine, c'est insupportable...
[^] # Re: Konqui
Posté par golum . Évalué à 10.
Désolé ========> [ ]
[^] # Re: Konqui
Posté par Matthieu . Évalué à 4.
parce que konqui, on en parle pas souvent :-P
(bien vu quand même)
[^] # Re: Konqui
Posté par divad . Évalué à -3.
[^] # Re: Konqui
Posté par Colin Pitrat (site web personnel) . Évalué à 4.
[^] # Re: Konqui
Posté par Zenitram (site web personnel) . Évalué à 4.
J'adore Linuxfr pour ca :-D
PS : pour alimenter le troll, FF me parait bien plus leger que Konqueror, en effet pour Konqueror faut lancer une bonne partie de KDE quand meme, c'est pas rien (ben oui, il y a des gens qui utilise autre chose que KDE, donc pour eux Konqueror est super-lourd... Donc lacher un "Konqueror c'est plus rapide au lancement" sans preciser dans quelles conditions, désolé mais c'est faux sans préciser que tu as lancé KDE avant. Ca depend de ce que tu as lancé avant)
[^] # Re: Konqui
Posté par TNorth . Évalué à 4.
Mais il me semble que l'atmosphère est un peu tendue ici :)
On ne peut plus donner son avis sans se faire traiter de troll vicieux...
Ce que j'aurais du rajouter, c'est "comme j'utilise KDE malgré ma petite machine, ... etc."
Il commence à falloir prendre beaucoup de précautions avant de poster, c'est désagréable...
Mais bon si tu insiste on peut s'enfoncer dedans : konqui au moins il passe le test acid2 ...
bon ok je sors -> [ ]
# Allocation de 500Mo de RAM pendant 30 seconde à l'ouverture d'une page
Posté par Julien Leroy . Évalué à 2.
Sous Windows(sic) la consultation du site de Dag Wieers sous FF 1.5 affole complètement le gestionnaire des tâches.
Le système devient inopérant pendant 30 longues secondes.
En observant la capacité mémoire on observe une allocation de 500 Mo pendant 30 secondes puis un retour à la normale.
Faites le test vous-même...
DAG: Red Hat/Fedora RPM package listing
http://dag.wieers.com/packages/
[^] # Re: Allocation de 500Mo de RAM pendant 30 seconde à l'ouverture d'une pa
Posté par Julien Leroy . Évalué à 1.
[^] # Re: Allocation de 500Mo de RAM pendant 30 seconde à l'ouverture d'une pa
Posté par Sixel . Évalué à 2.
3 secondes à charger la page, hausse de 7 Mo dans la consommation de mémoire (de 34 à 41 Mo) avec un pic à 45 Mo.
Par contre, une fois sur deux, ça me donne une page sans listing, et le reste du temps, ça me donne
This repository consists of 46294 RPM packages from 2469 different projects. suivi du listing...
C'est pas plutôt le site qui était foireux hier soir?
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
# XML
Posté par Boa Treize (site web personnel) . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.