Et pour Firefox que tu moque beaucoup. Pour un utilisateur comme toi qui utilise une partie réputé non assignée de la mémoire, ils ont des centaines de milliers d'utilisateurs qui se plaignent de sa lenteur. Ils font tout pour augmenter leur performance.
À la base de mes investigations, il y a le constat que Firefox marche moins bien quand on a beaucoup de mémoire.
C’est à dire qu’il y a une espèce de zone intermédiaire où Firefox marche mieux. Pas assez de mémoire ? Trop lent. Plein de mémoire ? Il s’étale, et ça devient gênant. J’ai vu des proches avoir des centaines d’onglets sur des machines à 8 ou 16Go et leur Firefox marchant mieux que moi sur une machine à 32Go.
Le coup du swap qui semble visiblement déterminer la capacité de Firefox à s’étendre est assez étonnant, ce n’est pas de la performance que de swaper ou d’invalider le cache disque qui pourrait bénéficier aux autres applications
J’ai vu des gens dire « j’ai assez de mémoire pour ne pas avoir de swap », au début quand je lisais cela je me disais que c’était bizarre car même sur des machines avec 30 ou 60Go le swap peut se retrouver utilisé même avec un swappiness qui dit de ne l’utiliser qu’en dernier recours, sauf que peut être que ça marche mieux sans swap en fait... Peut-être que certaines applications prennent plus de place (et donc provoquent plus de situation de swapper) s’il y a un swap.
Parce que zram expose du swap virtuel qui n’existe pas (vue décompressée de page mémoire compressée), il est possible qu’activer zram encourage certains programmes à occuper plus de mémoire et donc à réduir la mémoire réellement disponible en accès immédiat.
Il y a aussi bcache qui permet d’intercaler des SSDs entre des disques durs et la mémoire vive, et si le disque dur a été préparé pour cela, il est possible d’ajouter/retirer les SSDs à chaud.
Personne n’est contre la performance, mais il y a des pratiques qui peuvent-être contre-productives. Il y a une dizaine d’année il y avait une mode où plein de programmes sous Windows configuraient un démarrage à l’ouverture de session : tout et n’importe quoi se lançait à l’ouverture de session et se réduisait sous forme d’icône dans la tray bar. C’était sensé « accélérer l’ouverture des fichiers » et autre choses de ce genre, puisque le programme était déjà lancé. Sauf que rapidement la mémoire se trouvait occupée par des programmes qui ne servaient pas, et qui restaient ouvert avant et après qu’on ai édité un document, et puis l’ouverture de session était très lente. Une des premières opération pour rendre les performances d’origine aux machines constituait en la désactivation de tous ces programmes (coucou msconfig). Ce qui se passe avec Firefox (et il n’est probablement pas le seul) est du même ordre : le programme agit comme s’il était tout seul et que toute opération pour améliorer les performances est acceptable car l’idée de partager la machine semble étrangère. Par défaut le cache disque est configuré à 1Go, qu’est ce qui empêche de configurer par défaut le cache mémoire à 1 ou 2Go ? Ou un pourcentage ? Il est possible que la valeur du cache disque à 1Go soit un reliquat du passé puisqu’aujourd’hui le cache mémoire est très probablement plus large (puisque non limité), donc un pourcentage pourrait être une bonne idée.
Au passage, parmi les choses qui peuvent améliorer les performances (et prolonger la durée de vie) d’un ordinateur faisant tourner Firefox, il y a la clé browser.sessionstore.interval. Cette clé configure à quel rythme Firefox enregistre sur disque son état actuel, ce qui permet de récupérer ses onglets si l’ordinateur s’éteint de manière imprévue ou que Firefox crash dans cet intervalle. La valeur par défaut est de 15 secondes (15000). C’est très très court, sur certains systèmes et avec certains usages Firefox ne s’arrête jamais d’écrire... avec le risque que l’écriture de l’état courant dure plus de 15s. Et ça peut évidemment ralentir les IO des autres programmes en se mettant en travers (surtout sur les stockages dont les accès aléatoires sont lent !). Actuellement cette valeur est assignée à 2 minutes (120000) de mon côté, ça veut dire que si j’ai un crash, au pire je perds ce que j’ai fait dans les 2 dernières minutes. C’est un compromis acceptable à mes yeux.
Là, 15s est la valeur par défaut car considéré comme « safety critical for many users », voir ce commentaire d’un développeur de Firefox. La conversation date de 2016 et je ne sais pas trop où ça en est mais à l’époque il était dit :
we are aware of the problem, but fixing it for real requires completely re-architecturing Session Restore. That’s something we haven’t done yet, as Session Restore is rather safety-critical for many users, so this would need to be done very carefully, and with plenty of manpower.
A significant amount of work happened since this bug was first filed that has reduced the severity of the problem.
There's still more that can be done, that's why this bug is marked up as a metabug and there are still open related bugs.
Je ne sais donc pas trop où ça en est, mais j’ai moi aussi remarqué la quantité énorme d’écritures que rapportait mon système. J’ai aussi remarqué le réveil fréquent de certains disques. Je parlais d’un script qui réduit la consommation ou endort certains composants sans tout suspendre, quand une machine a un bcache avec ce genre de script je peux aussi mettre le bcache en writeback et suspendre les disques durs, sauf que si Firefox n’est pas suspendu, les disques durs sont très vite réveillés, évidemment, parce qu’à un moment le cache en écriture atteint un seuil qui déclenche l’écriture sous-jacente ou bien diverses lectures sont faites par le même processus qui va écrire, et plus ça fait d’IO et plus il y a de chance que ça fasse une opération hors-cache. Bon, ce genre de chose est sensée ne pas se produire quand Firefox détecte qu’il est en train d’« idle », mais je ne suis pas certain que cette détection fonctionne toujours.
Et comme certains le font remarquer sur le ticket, ce genre de comportement peut être gênant sur des disques réseau... Ce qui peut sembler performant, fiable, etc. à première vue peut ne l’être que dans des cas déterminés. Ce qui peut sembler évident diffère selon qu’on suppose qu’un programme soit seul ou non, par exemple.
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é à 6. Dernière modification le 18 juin 2022 à 15:40.
À la base de mes investigations, il y a le constat que Firefox marche moins bien quand on a beaucoup de mémoire.
C’est à dire qu’il y a une espèce de zone intermédiaire où Firefox marche mieux. Pas assez de mémoire ? Trop lent. Plein de mémoire ? Il s’étale, et ça devient gênant. J’ai vu des proches avoir des centaines d’onglets sur des machines à 8 ou 16Go et leur Firefox marchant mieux que moi sur une machine à 32Go.
Le coup du swap qui semble visiblement déterminer la capacité de Firefox à s’étendre est assez étonnant, ce n’est pas de la performance que de swaper ou d’invalider le cache disque qui pourrait bénéficier aux autres applications
J’ai vu des gens dire « j’ai assez de mémoire pour ne pas avoir de swap », au début quand je lisais cela je me disais que c’était bizarre car même sur des machines avec 30 ou 60Go le swap peut se retrouver utilisé même avec un swappiness qui dit de ne l’utiliser qu’en dernier recours, sauf que peut être que ça marche mieux sans swap en fait... Peut-être que certaines applications prennent plus de place (et donc provoquent plus de situation de swapper) s’il y a un swap.
Parce que zram expose du swap virtuel qui n’existe pas (vue décompressée de page mémoire compressée), il est possible qu’activer zram encourage certains programmes à occuper plus de mémoire et donc à réduir la mémoire réellement disponible en accès immédiat.
Il y a aussi bcache qui permet d’intercaler des SSDs entre des disques durs et la mémoire vive, et si le disque dur a été préparé pour cela, il est possible d’ajouter/retirer les SSDs à chaud.
Personne n’est contre la performance, mais il y a des pratiques qui peuvent-être contre-productives. Il y a une dizaine d’année il y avait une mode où plein de programmes sous Windows configuraient un démarrage à l’ouverture de session : tout et n’importe quoi se lançait à l’ouverture de session et se réduisait sous forme d’icône dans la tray bar. C’était sensé « accélérer l’ouverture des fichiers » et autre choses de ce genre, puisque le programme était déjà lancé. Sauf que rapidement la mémoire se trouvait occupée par des programmes qui ne servaient pas, et qui restaient ouvert avant et après qu’on ai édité un document, et puis l’ouverture de session était très lente. Une des premières opération pour rendre les performances d’origine aux machines constituait en la désactivation de tous ces programmes (coucou
msconfig). Ce qui se passe avec Firefox (et il n’est probablement pas le seul) est du même ordre : le programme agit comme s’il était tout seul et que toute opération pour améliorer les performances est acceptable car l’idée de partager la machine semble étrangère. Par défaut le cache disque est configuré à 1Go, qu’est ce qui empêche de configurer par défaut le cache mémoire à 1 ou 2Go ? Ou un pourcentage ? Il est possible que la valeur du cache disque à 1Go soit un reliquat du passé puisqu’aujourd’hui le cache mémoire est très probablement plus large (puisque non limité), donc un pourcentage pourrait être une bonne idée.Au passage, parmi les choses qui peuvent améliorer les performances (et prolonger la durée de vie) d’un ordinateur faisant tourner Firefox, il y a la clé
browser.sessionstore.interval. Cette clé configure à quel rythme Firefox enregistre sur disque son état actuel, ce qui permet de récupérer ses onglets si l’ordinateur s’éteint de manière imprévue ou que Firefox crash dans cet intervalle. La valeur par défaut est de 15 secondes (15000). C’est très très court, sur certains systèmes et avec certains usages Firefox ne s’arrête jamais d’écrire... avec le risque que l’écriture de l’état courant dure plus de 15s. Et ça peut évidemment ralentir les IO des autres programmes en se mettant en travers (surtout sur les stockages dont les accès aléatoires sont lent !). Actuellement cette valeur est assignée à 2 minutes (120000) de mon côté, ça veut dire que si j’ai un crash, au pire je perds ce que j’ai fait dans les 2 dernières minutes. C’est un compromis acceptable à mes yeux.Là, 15s est la valeur par défaut car considéré comme « safety critical for many users », voir ce commentaire d’un développeur de Firefox. La conversation date de 2016 et je ne sais pas trop où ça en est mais à l’époque il était dit :
Le ticket est toujours ouvert. Le dernier commentaire d’il y a trois ans dit:
Je ne sais donc pas trop où ça en est, mais j’ai moi aussi remarqué la quantité énorme d’écritures que rapportait mon système. J’ai aussi remarqué le réveil fréquent de certains disques. Je parlais d’un script qui réduit la consommation ou endort certains composants sans tout suspendre, quand une machine a un bcache avec ce genre de script je peux aussi mettre le bcache en writeback et suspendre les disques durs, sauf que si Firefox n’est pas suspendu, les disques durs sont très vite réveillés, évidemment, parce qu’à un moment le cache en écriture atteint un seuil qui déclenche l’écriture sous-jacente ou bien diverses lectures sont faites par le même processus qui va écrire, et plus ça fait d’IO et plus il y a de chance que ça fasse une opération hors-cache. Bon, ce genre de chose est sensée ne pas se produire quand Firefox détecte qu’il est en train d’« idle », mais je ne suis pas certain que cette détection fonctionne toujours.
Et comme certains le font remarquer sur le ticket, ce genre de comportement peut être gênant sur des disques réseau... Ce qui peut sembler performant, fiable, etc. à première vue peut ne l’être que dans des cas déterminés. Ce qui peut sembler évident diffère selon qu’on suppose qu’un programme soit seul ou non, par exemple.
ce commentaire est sous licence cc by 4 et précédentes