Ta thèse c'est que Firefox n'est pas optimal en particulier quand tu as plus de 32Gio de RAM et que tu l'utilise sur des disques en réseau ?
Non.
Je n’ai pas dit qu’il fallait ces deux conditions.
J’ai aussi dit que j’avais des problèmes même avec pas plus que 32Go de ram.
Et il a été ajouté (et je le confirme moi-même, ça m’était juste sorti de l’esprit), que ce qui pourrait faire la ou une différence serait la quantité de swap réelle ou virtuelle (zram).
Merci de ne pas fabriquer d’homme de paille.
Je donne plusieurs exemples de contextes qui peuvent être indépendants, et je donne les suivants après que j’ai cité les précédents comme suffisants pour reproduire les problèmes, et je cite aussi divers problèmes qui peuvent se télescoper. Ça signifie que ces problèmes peuvent toucher des personnes différentes qui ne partagent pas forcément mes besoin ni les mêmes fournitures, c’est à dire que j’étends la couverture à une population plus large, et toi tu transformes ça en une espèce de « il faut cocher toute les cases en même temps » ce qui réduit drastiquement la couverture jusqu‘à en faire une exception. Je fait un ou inclusif, tu en fait un et.
Je cite le cas du disque réseau (ce qui n’est pas mon usage, là tout de suite, mais j’ai aussi rencontré ce problème ou vu d’autres personnes rencontrer ce problème), mais je fais aussi un lien vers un article de quelqu’un qui parle de SSD, etc. Je parle du fait que le cache mémoire ne soit pas plafonné alors que le cache disque l’est (et est probablement plus petit que le cache mémoire réel) et j’ai ajouté le fait que Firefox écrit toutes les 15s. Il y a plein de scénarios où ça peut poser problème.
Pour le premier problème, le plus évident c’est quand quelqu’un investit de la mémoire pour une application spécifique et que Firefox la mange à la place.
Pour le second problème, ça peut concerner un disque réseau, disque mécanique, disque mécanique avec SMR (qui a une tête plus large que la piste, en gros, donc écrire une piste implique de réécrire plusieurs pistes, sachant que certains fabriquant dissimulent cette information), disque USB (c’est très pratique d’avoir un système portable avec son bureau dans la poche), etc. Et d’ailleurs ces écritures toutes les 15s peuvent aussi déclencher l’invalidation du cache disque au détriment d’autres applications qui pourraient être jugées plus productives, donc les deux problèmes peuvent se télescoper.
Dois-je rappeler que le dimensionnement de la mémoire est aujourd’hui contrainte par le prix ? et le fait qu’il est plus facile de faire un compromis sur la mémoire que sur la carte graphique et que cette dernière souffre également d’une envolée des prix ?
16Go aujourd’hui c’est le standard pour le matériel reconditionné (exemple), et ce depuis deux ou trois ans déjà. Beaucoup d’ordinateurs de joueurs n’ont pas plus parce que c’est la dèche. Ça fait 7 ou 8 ans que la mémoire stagne à 16Go ! Exemple: Best Gaming PC Build Under 1,500ドル [November 2015] : 16Go de ram, et c’était déjà de la DDR4.
Et en fait il y a 10 ans avoir 16Go de ram c’était déjà super accessible, exemple High End Gaming Performance Under 1,000 [December 2012], avec 40$ les 8Go. Donc on était encore loin en dessous de 1500$ pour un PC "high end gaming" 16Go il y a 10 ans. 16Go ça coûtait 80€ les 2 barrettes. 32Go ça coûtait 160€ les 4 barrettes (les cartes mères avaient déjà 4 slots, pas de coût caché). Sur le lien que tu donnes, 16Go coûte aujourd’hui 95,ドル donc 190€ les 32Go. Sachant qu’entre temps l’inflation s’est envolée et que les ressources des ménages ont énormément baissées.
Alors oui, tailler un Firefox qui marche bien quand il y a 16Go est normal vu que c’est ce que c’est ce qu’il y a sur le marché et ce depuis presque 10 ans. Mais ça ne justifie pas de ne pas mettre de limite haute par exemple.
Tu utilise une fonctionnalité qui passe sous les radar
Je donne ces exemples précis car le constat est aisé, je veux bien admettre que ces exemples sont spécifiques, mais je les ai choisis car évidents, et ils sont assez hors-norme pour que justement le constat soit évident et ne relève pas de la marge d’erreur. Mais oui toutes les applications qui font des lectures font appel au cache disque et sont donc concernées par l’invalidation du cache à cause d’une application qui s’étale, toutes les applications qui écrivent sont concernées par des écritures toute les 15s qui randomisent les accès et peuvent fragmenter le système de fichier.
Ce n’est pas parce que quelqu’un ne se soucie pas de savoir ce qui est en cache ou pas qu’il n’est pas ralenti dans le montage de sa vidéo de vacance parce que Firefox se met à l’aise. Ne pas savoir être affecté n’est pas pareil que ne pas être affecté.
Ça fait 5~6 ans que je me rend compte que sur ma machine avec 32Go Firefox marchait moins bien que sur ma machine avec 16Go et que chez des proches avec 8 ou 16Go. Jusque là ça je m’en satisfaisait en me disant « je verrai plus tard » et en râlant intérieurement. Et puis quand j’ai vu qu’avec 200Go de mémoire Firefox peut en manger 100... Là je me suis décidé à chercher.
Je vais donner un autre exemple. Débuguer un pilote Mesa comme radeonsi ou clover peut requérir de recompiler Mesa depuis la branche main, mais ces pilotes sont intimement liés à LLVM, donc cela peut requérir de recompiler aussi LLVM depuis la branche main. Compiler LLVM en mode Debug ça peut prendre entre 6 et 8Go de mémoire par job. Sur une machine avec 16/32 Cœurs, ça veut dire qu’un meson compile -j$(nproc) va bouffer entre 192 et 256Go de ram, en fait un peu moins car tous les jobs ne vont pas faire 8Go et il y a une espèce de traîne, mais tu vois l’idée. J’ai écrit un script pour recompiler LLVM et Mesa et au moment de recompiler LLVM, le script récupère la quantité de mémoire disponible, divise par 8 et passe ce nombre à meson comme nombre de jobs de compilation parallèle à lancer.
Débuguer un pilote va donc doubler ou tripler le nombre d’heures à passer en fonction de ce que décide Firefox, parce que « je suis bien content de ne pas me payer des barrettes de RAM pour le plaisir de vérifier qu'elles ne sont pas utilisées » ?.
Là encore je prends un cas extrême (mais clairement identifiable), OK, mais en fait le problème que je pointe se présente dès lors que l’application principale de l’ordinateur demande plus de mémoire que Firefox, ou traite des gros fichiers, et qu’on a éventuellement investi de la mémoire pour cette application principale et non pas pour Firefox. Un joueur, un monteur de vidéo, quelqu’un qui compile de gros programmes (compilateur, noyau, suite office...) et tout plein d’usages qui peuvent réclamer de la mémoire peuvent être affectés par ce problème, même si c’est inconscient.
Et puis ça amène des choses étonnantes ! Si quelqu’un se dit « je n’ai pas beaucoup besoin de swap sur mon ordi fixe car je n’hibernerai pas mais je vais mettre beaucoup de swap sur mon ordi portable pour pouvoir hiberner », il va penser que son ordi portable a des problèmes ou qu’il est plus lent pour une raison qui lui échappe. Et puis s’il applique la vieille règle de « la taille du swap est le double de la ram » pour se permettre d’hiberner même s’il swappe déjà parce qu’il a des gros programmes, passer de 16 à 32Go risque en fait de conduire Firefox à penser qu’il passe de 48Go à 96Go, et donc qu’il y a 48Go disponible en plus alors qu’il n’y a que 16Go disponible en plus en ram ! Et ce au détriment de toutes les autres applications !
Personnellement quand quelqu’un me demande en quoi c’est mieux d’avoir plus de ram, je réponds « le cache disque », je ne dis pas aux gens de faire l’astuce du dd pour précharger les fichiers, non, non, je dis simplement que tout ce qui est écrit et lu ne sera plus jamais relu depuis le disque dur si la mémoire est assez grande pour ne pas devoir « oublier » le contenu du fichier. C’est à dire que pour quelqu’un qui n’a que des programmes qui prennent pas plus que 8 Go, s’il peut se payer 32Go c’est tout de même mieux que 16Go. Toute mémoire en rab est du cache en rab. Je donne souvent l’exemple du Jeu de pousse-pousse, la quantité de mémoire est parfaitement adaptée à la quantité de données traitées, mais le traitement est fastidieux et long, et tout case vide supplémentaire rendrait plus facile le traitement. Je donne aussi l’exemple d’un bureau où l’on aurait la place de mettre deux livres côte à côte et un autre bureau plus petit où l’on devrait les mettre l’un sur l’autre, et qu’on veut en faire une étude comparée (sachant qu’en plus en ram il n’y a même pas de notion de distance). Ces métaphores fonctionnent très bien.
La mémoire en rab, c’est du cache disque avec l’accès le plus rapide du monde ! Alors c’est vrai aussi pour le web, sauf que le web a une sacré tendance à t’afficher mille choses dont tu n’as pas besoin. Si quelqu’un ne va que sur des sites qui ne lui affichent que ce que dont il a besoin, le problème que je décris ne le concerne pas, c’est vrai, mais par contre ça c’est désormais un cas d’usage vraiment très spécifique et anecdotique.
Nos sites web modernes sont blindés de changement dynamiques, de défilement infini, et ça ne s’arrête jamais (et je ne parle pas des pubs, qui sont bloquées chez moi). Le web ne dors jamais et les sites web se rafraîchissent tous seul, d’où le besoin de plafonner la mémoire immédiate affectée à retenir la soupe qui sort de ce robinet grand ouvert.
Jamais je n’aurai imaginé qu’un changement aussi simple que changer ce genre de clé aurait eu un tel impact sur l’utilisabilité des machines !
Ah oui aussi, il peut être intéressant d’aller sur about:memory et de cliquer sur les 3 boutons GC, CC et Minimize memory usage, notamment après avoir plafonné la valeur de browser.cache.memory.capacity dans about:config. Ça peut récupérer une poignée de Go pour celui qui voudrait faire de la place pour une autre application.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pas de swap ... pas de problème
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Zswap, ZRam, EarlyOOM... organiser la gestion d'une pénurie de mémoire vive. Évalué à 7.
Non.
Je n’ai pas dit qu’il fallait ces deux conditions.
J’ai aussi dit que j’avais des problèmes même avec pas plus que 32Go de ram.
Et il a été ajouté (et je le confirme moi-même, ça m’était juste sorti de l’esprit), que ce qui pourrait faire la ou une différence serait la quantité de swap réelle ou virtuelle (zram).
Merci de ne pas fabriquer d’homme de paille.
Je donne plusieurs exemples de contextes qui peuvent être indépendants, et je donne les suivants après que j’ai cité les précédents comme suffisants pour reproduire les problèmes, et je cite aussi divers problèmes qui peuvent se télescoper. Ça signifie que ces problèmes peuvent toucher des personnes différentes qui ne partagent pas forcément mes besoin ni les mêmes fournitures, c’est à dire que j’étends la couverture à une population plus large, et toi tu transformes ça en une espèce de « il faut cocher toute les cases en même temps » ce qui réduit drastiquement la couverture jusqu‘à en faire une exception. Je fait un ou inclusif, tu en fait un et.
Je cite le cas du disque réseau (ce qui n’est pas mon usage, là tout de suite, mais j’ai aussi rencontré ce problème ou vu d’autres personnes rencontrer ce problème), mais je fais aussi un lien vers un article de quelqu’un qui parle de SSD, etc. Je parle du fait que le cache mémoire ne soit pas plafonné alors que le cache disque l’est (et est probablement plus petit que le cache mémoire réel) et j’ai ajouté le fait que Firefox écrit toutes les 15s. Il y a plein de scénarios où ça peut poser problème.
Pour le premier problème, le plus évident c’est quand quelqu’un investit de la mémoire pour une application spécifique et que Firefox la mange à la place.
Pour le second problème, ça peut concerner un disque réseau, disque mécanique, disque mécanique avec SMR (qui a une tête plus large que la piste, en gros, donc écrire une piste implique de réécrire plusieurs pistes, sachant que certains fabriquant dissimulent cette information), disque USB (c’est très pratique d’avoir un système portable avec son bureau dans la poche), etc. Et d’ailleurs ces écritures toutes les 15s peuvent aussi déclencher l’invalidation du cache disque au détriment d’autres applications qui pourraient être jugées plus productives, donc les deux problèmes peuvent se télescoper.
Dois-je rappeler que le dimensionnement de la mémoire est aujourd’hui contrainte par le prix ? et le fait qu’il est plus facile de faire un compromis sur la mémoire que sur la carte graphique et que cette dernière souffre également d’une envolée des prix ?
16Go aujourd’hui c’est le standard pour le matériel reconditionné (exemple), et ce depuis deux ou trois ans déjà. Beaucoup d’ordinateurs de joueurs n’ont pas plus parce que c’est la dèche. Ça fait 7 ou 8 ans que la mémoire stagne à 16Go ! Exemple: Best Gaming PC Build Under 1,500ドル [November 2015] : 16Go de ram, et c’était déjà de la DDR4.
Et en fait il y a 10 ans avoir 16Go de ram c’était déjà super accessible, exemple High End Gaming Performance Under 1,000 [December 2012], avec 40$ les 8Go. Donc on était encore loin en dessous de 1500$ pour un PC "high end gaming" 16Go il y a 10 ans. 16Go ça coûtait 80€ les 2 barrettes. 32Go ça coûtait 160€ les 4 barrettes (les cartes mères avaient déjà 4 slots, pas de coût caché). Sur le lien que tu donnes, 16Go coûte aujourd’hui 95,ドル donc 190€ les 32Go. Sachant qu’entre temps l’inflation s’est envolée et que les ressources des ménages ont énormément baissées.
Alors oui, tailler un Firefox qui marche bien quand il y a 16Go est normal vu que c’est ce que c’est ce qu’il y a sur le marché et ce depuis presque 10 ans. Mais ça ne justifie pas de ne pas mettre de limite haute par exemple.
Je donne ces exemples précis car le constat est aisé, je veux bien admettre que ces exemples sont spécifiques, mais je les ai choisis car évidents, et ils sont assez hors-norme pour que justement le constat soit évident et ne relève pas de la marge d’erreur. Mais oui toutes les applications qui font des lectures font appel au cache disque et sont donc concernées par l’invalidation du cache à cause d’une application qui s’étale, toutes les applications qui écrivent sont concernées par des écritures toute les 15s qui randomisent les accès et peuvent fragmenter le système de fichier.
Ce n’est pas parce que quelqu’un ne se soucie pas de savoir ce qui est en cache ou pas qu’il n’est pas ralenti dans le montage de sa vidéo de vacance parce que Firefox se met à l’aise. Ne pas savoir être affecté n’est pas pareil que ne pas être affecté.
Ça fait 5~6 ans que je me rend compte que sur ma machine avec 32Go Firefox marchait moins bien que sur ma machine avec 16Go et que chez des proches avec 8 ou 16Go. Jusque là ça je m’en satisfaisait en me disant « je verrai plus tard » et en râlant intérieurement. Et puis quand j’ai vu qu’avec 200Go de mémoire Firefox peut en manger 100... Là je me suis décidé à chercher.
Je vais donner un autre exemple. Débuguer un pilote Mesa comme radeonsi ou clover peut requérir de recompiler Mesa depuis la branche
main, mais ces pilotes sont intimement liés à LLVM, donc cela peut requérir de recompiler aussi LLVM depuis la branchemain. Compiler LLVM en mode Debug ça peut prendre entre 6 et 8Go de mémoire par job. Sur une machine avec 16/32 Cœurs, ça veut dire qu’unmeson compile -j$(nproc)va bouffer entre 192 et 256Go de ram, en fait un peu moins car tous les jobs ne vont pas faire 8Go et il y a une espèce de traîne, mais tu vois l’idée. J’ai écrit un script pour recompiler LLVM et Mesa et au moment de recompiler LLVM, le script récupère la quantité de mémoire disponible, divise par 8 et passe ce nombre à meson comme nombre de jobs de compilation parallèle à lancer.Débuguer un pilote va donc doubler ou tripler le nombre d’heures à passer en fonction de ce que décide Firefox, parce que « je suis bien content de ne pas me payer des barrettes de RAM pour le plaisir de vérifier qu'elles ne sont pas utilisées » ?.
Là encore je prends un cas extrême (mais clairement identifiable), OK, mais en fait le problème que je pointe se présente dès lors que l’application principale de l’ordinateur demande plus de mémoire que Firefox, ou traite des gros fichiers, et qu’on a éventuellement investi de la mémoire pour cette application principale et non pas pour Firefox. Un joueur, un monteur de vidéo, quelqu’un qui compile de gros programmes (compilateur, noyau, suite office...) et tout plein d’usages qui peuvent réclamer de la mémoire peuvent être affectés par ce problème, même si c’est inconscient.
Et puis ça amène des choses étonnantes ! Si quelqu’un se dit « je n’ai pas beaucoup besoin de swap sur mon ordi fixe car je n’hibernerai pas mais je vais mettre beaucoup de swap sur mon ordi portable pour pouvoir hiberner », il va penser que son ordi portable a des problèmes ou qu’il est plus lent pour une raison qui lui échappe. Et puis s’il applique la vieille règle de « la taille du swap est le double de la ram » pour se permettre d’hiberner même s’il swappe déjà parce qu’il a des gros programmes, passer de 16 à 32Go risque en fait de conduire Firefox à penser qu’il passe de 48Go à 96Go, et donc qu’il y a 48Go disponible en plus alors qu’il n’y a que 16Go disponible en plus en ram ! Et ce au détriment de toutes les autres applications !
Personnellement quand quelqu’un me demande en quoi c’est mieux d’avoir plus de ram, je réponds « le cache disque », je ne dis pas aux gens de faire l’astuce du
ddpour précharger les fichiers, non, non, je dis simplement que tout ce qui est écrit et lu ne sera plus jamais relu depuis le disque dur si la mémoire est assez grande pour ne pas devoir « oublier » le contenu du fichier. C’est à dire que pour quelqu’un qui n’a que des programmes qui prennent pas plus que 8 Go, s’il peut se payer 32Go c’est tout de même mieux que 16Go. Toute mémoire en rab est du cache en rab. Je donne souvent l’exemple du Jeu de pousse-pousse, la quantité de mémoire est parfaitement adaptée à la quantité de données traitées, mais le traitement est fastidieux et long, et tout case vide supplémentaire rendrait plus facile le traitement. Je donne aussi l’exemple d’un bureau où l’on aurait la place de mettre deux livres côte à côte et un autre bureau plus petit où l’on devrait les mettre l’un sur l’autre, et qu’on veut en faire une étude comparée (sachant qu’en plus en ram il n’y a même pas de notion de distance). Ces métaphores fonctionnent très bien.La mémoire en rab, c’est du cache disque avec l’accès le plus rapide du monde ! Alors c’est vrai aussi pour le web, sauf que le web a une sacré tendance à t’afficher mille choses dont tu n’as pas besoin. Si quelqu’un ne va que sur des sites qui ne lui affichent que ce que dont il a besoin, le problème que je décris ne le concerne pas, c’est vrai, mais par contre ça c’est désormais un cas d’usage vraiment très spécifique et anecdotique.
Nos sites web modernes sont blindés de changement dynamiques, de défilement infini, et ça ne s’arrête jamais (et je ne parle pas des pubs, qui sont bloquées chez moi). Le web ne dors jamais et les sites web se rafraîchissent tous seul, d’où le besoin de plafonner la mémoire immédiate affectée à retenir la soupe qui sort de ce robinet grand ouvert.
Jamais je n’aurai imaginé qu’un changement aussi simple que changer ce genre de clé aurait eu un tel impact sur l’utilisabilité des machines !
Ah oui aussi, il peut être intéressant d’aller sur
about:memoryet de cliquer sur les 3 boutonsGC,CCetMinimize memory usage, notamment après avoir plafonné la valeur debrowser.cache.memory.capacitydansabout:config. Ça peut récupérer une poignée de Go pour celui qui voudrait faire de la place pour une autre application.ce commentaire est sous licence cc by 4 et précédentes