Journal Zswap, ZRam, EarlyOOM... organiser la gestion d'une pénurie de mémoire vive

Posté par  (site Web personnel) . Licence CC By‑SA.
Étiquettes :
17
15
juin
2022

Hello nal,

Il était une fois

Sur mon SSD, j'avais l'habitude d'activer ZRam comme indiqué sur le wiki de sebsauvage.net.

Jusque là « ma vie était plutôt simple » (tous droits réservés).

Puis j'ai lu un peu de doc sur EarlyOOM qui est utilisé dans Fedora 32, Clear Linux…

… mais il y a aussi OOMD de Facebook qui est arrivé après et nécessite Linux 4.20 (liens 1, 2 et 3)

Et puis finalement j'entends parler de Zswap que serait mieux que Zram.

À présent

Bon, du coup j'ai bricolé un peu hasard de mes lectures (une démarche sécurisée, toujours recommandée).

Finalement j'ai désactivé Zram au profit de Zswap et EarlyOOM.

A noter que sur ma Debian testing fraîchement réinstallée, je n'avais pas lz4 que j'ai dû ajouter. Et que même ainsi, Zswap ne s'appuie pas dessus mais sur lzo semble t-il :

grep -R . /sys/module/zswap/parameters
/sys/module/zswap/parameters/same_filled_pages_enabled:Y
/sys/module/zswap/parameters/enabled:Y
/sys/module/zswap/parameters/max_pool_percent:25
/sys/module/zswap/parameters/compressor:lzo
/sys/module/zswap/parameters/non_same_filled_pages_enabled:Y
/sys/module/zswap/parameters/zpool:z3fold
/sys/module/zswap/parameters/accept_threshold_percent:90

Cf aussi :

dmesg | grep zswap
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.18.0-1-amd64 root=UUID=55a67d5b-ea0a-451a-9cbb-1cfcb178dee1 ro quiet zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=25 zswap.zpool=z3fold
[ 0.022423] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.18.0-1-amd64 root=UUID=55a67d5b-ea0a-451a-9cbb-1cfcb178dee1 ro quiet zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=25 zswap.zpool=z3fold
[ 0.376491] zswap: compressor lz4 not available, using default lzo
[ 0.379879] zswap: loaded using pool lzo/z3fold

Mais au fait, on parle de quoi ?

De mon bon vieux PC desktop inchangé depuis 10 ans à usage personnel :
Processeur double-cœurs Intel Core i3-3225
RAM 8 Go
SSD Crucial M4 de 64 Go avec 1 Go de swap
Debian testing avec Linux 5.18
GNOME Wayland

Et alors ?

Vous préconisez quoi ?

  • # Erratum

    Posté par  (site Web personnel) . Évalué à 4 (+2/-1).

  • # Manjaro

    Posté par  . Évalué à 2 (+1/-1).

    Mmmm merci je comprenais pas pourquoi mon PC semblait mieux gerer la RAM sans rien qu'avec zram depuis je suis passe de ubuntu a manjaro.

    Il semblerait que zswap soit installe par defaut avec Manjaro, en tous cas il est installe sur ma machine sans que je me souvienne l'avoir fait. Et effectivement, c'est nettement mieux :-)

  • # Différence zram/zswap

    Posté par  . Évalué à 4 (+5/-1).

    Il y a une différence assez importante entre zram et zswap :

    • zram crée un ramdisk compressé, qu'on peut ensuite utiliser comme n'importe quel autre block device
    • zswap est une sorte de cache compressé dans la ram où sont envoyées les données à destination de la swap

    zram est "aunotome", alors que zswap nécessite en plus un espace de swap existant (quelle que soit sa forme). Sur mes machines ARM qui fonctionnent sur une carte SD, j'utilise zram, puisque je ne mets pas d'espace de swap sur la carte SD :)

  • # Pas de swap … pas de problème

    Posté par  . Évalué à 4 (+2/-0).

    J'ai la chance d'avoir une machine avec assez de mémoire pour ne jamais la saturer.

    Le seul point que je ne me résous à déplacer en RAM est les log, il faut que je regarde ce qui pourrais tout mettre en RAM et seulement a l'extinction de la machine passer le tout sur disque.

    • [^] # Re: Pas de swap … pas de problème

      Posté par  (site Web personnel) . Évalué à 5 (+4/-0).

      La solution existe : Log2ram. Korben l'explique dans un article de 2020 : https://korben.info/carte-sd-raspberry-pi-duree-de-vie-m.html

    • [^] # Re: Pas de swap … pas de problème

      Posté par  (site Web personnel) . Évalué à 10 (+8/-0).

      J'ai la chance d'avoir une machine avec assez de mémoire pour ne jamais la saturer.

      Je ne serai pas aussi prompt à l’affirmer. Saturer, peut-être pas, mais quelque soit la taille de ta mémoire, tu pourras toujours avoir des trucs qui l’occupent au détriment de ce dont tu as besoin.

      Il semble que certaines applications s’étendent autant qu’elles peuvent, alors chaque application ne va peut-être pas tenter de saturer, mais tu peux te faire surprendre.

      Je m’explique, j’ai plusieurs machines de plusieurs générations et de taille de mémoire différentes : une poignée de Go de ram, 16Go, 32Go, 256Go. La machine qui a 256Go avait 128Go il y a quelque mois et j’ai pu comparer le même usage avec la même installation, et en fait le système a été déplacé depuis la machine qui a 32Go donc j’ai pu aussi comparer.

      Avec les mêmes usages, sur la machine à 32Go la somme de certaines grosses applis comme Firefox atteignait facilement 16Go. Pourtant ces applis n’atteignent pas 16Go de RAM sur mon laptop avec 16Go de ram. Et autour de moi j’en vois bien utiliser Firefox sur des machines à 8Go de RAM avec dix mille onglets. Pourtant si je fais pareil ça explose de mon côté, ça explose d’autant que j’ai de la RAM. Avec 128Go, c’est devenu complètement dingue, avec Firefox bouffant parfois 64 ou 96Go de ram, c’est complètement indécent. Et une fois passé à 256Go de RAM Firefox s’est mis à manger 128Go… quoi???!!!!!

      J’ai aussi essayé une chose mais je ne pourrai que l’évaluer dans la durée. Depuis longtemps j’utilise /tmp en tmpfs (pour la performance), mais je soupçonne des applications d’ouvrir des fichiers temporaires, d’écrire dedans, de les supprimer mais de ne pas les fermer (et donc ils resteraient alloués en RAM). Donc pour le moment je suis revenu à un /tmp sur disque, pour voir. Je peux difficilement mesurer mais il me semble que la RAM occupée monte moins, mais monte toujours.

      Donc ces derniers jours j’ai cherché à voir où partait la mémoire ! Il n’est pas rare que dans le gestionnaire des tâches de GNOME (gnome-system-monitor) je vois des processus Firefox qui mangent 1 Go et plus ! Parfois 6 Go ! Si je tue ce type de processus, un onglet quelque part me dit qu’il a crashé et que je peux le recharger (bonne astuce !). C’est plus efficace que la page about:performance qui ne renvoie pas de valeur fiable et sur laquelle on ne peut pas compter.

      Et puis j’ai découvert la clé Firefox browser.cache.memory.capacity qui détermine le cache en mémoire vive de Firefox. Par défaut elle est mise à -1 ça veut dire, pas de limite haute ! La machine est super stable, la dernière fois que je l’ai rebootée pour installer un nouveau composant elle avait un uptime de deux mois ! Alors je ne sais pas combien prenait Firefox pour son cache mémoire, mais ça devait être dingue !

      J’ai mis la limite browser.cache.memory.capacity à 2000000 pour 2Go de cache en mémoire, ce qui le plafonne (et j’ai mis pareil à browser.cache.disk.capacity, au lieu de 2560Mo, ce qui l’augmente), et franchement, ça va beaucoup mieux ! Je n’ai plus de Firefox qui se met à bouffer 100Go, et c’est toujours plus gourmand que sur une machine à 16 ou 32Go mais ça reste contenu.

      Mais dans l’immédiat j’avais toujours beaucoup de mémoire utilisée. Quand j’ai fait ces tests pour récupérer ma mémoire la machine avait 20 jours d’uptime et une 100aine de Go utilisés. Je n’ai pas redémarré mais j’ai tout tué dans la session utilisateur, y compris la session utilisateur. J’en ai récupéré 20-30Go… quoi ??? ils sont où tout les autres ?

      Parce qu’indépendamment des applications, je voyais ma RAM occupée monter, monter, monter… et en effet même après avoir fermé toutes les applications, je ne récupérais pas tout, même après avoir fermé et ré-ouvert la session utilisateur.

      Alors j’ai essayé plus de trucs.

      Il ne faut pas confondre le cache mémoire et la mémoire, et je ne le confonds pas, et pourtant. J’ai vérifié, que si je faisais ceci :

      echo 3 > /proc/sys/vm/drop_caches

      je pouvais libérer non seulement une centaine de Go en cache (normal ! c’est aussi pour ça que cette machine a autant de mémoire, pour pouvoir traiter des fichiers de 100Go en cache mémoire !) mais surtout j’ai récupéré plusieurs dizaines de Go de mémoire non-cache, 30Go peut-être ?! Quoi ? Comment ?

      Et puis j’ai fait un deuxième chose, après avoir fermé toutes mes applications, après avoir vidé le cache qui semble affecter des trucs en mémoire quand même™, j’ai fait ceci :

      echo N > /sys/module/zswap/parameters/enabled
      swapoff -a; swapon -a
      echo Y > /sys/module/zswap/parameters/enabled

      Ces commandes désactivent zswap, désactivent le swap et le réactivent, puis réactivent zswap.

      En faisant cela, 5Go a été libéré du swap, et environ 20-30Go on été libérés de la RAM, simplement en désactivant zswap et le swap et en réactivant tout cela après.

      Alors je ne sais pas s’il y a un bug dans zswap où je ne sais pas quoi d’autre, mais wow, clairement cette mémoire était occupée pour rien.

      Avant de fermer mes applications j’avais autour de 100Go d’utilisé, après les avoir fermées j’en avais autour de 60~80Go, après avoir vidé le cache (qui semble vider plus que du cache !), désactivé zswap et désactivé le swap (et réactivé les deux), je suis tombé à ~7Go de mémoire utilisée (toujours 20 jours d’uptime). C’était encore beaucoup trop… j’ai sous la main quelques machines avec 8Go et le système ne prend que quelques centaines de Mo. Mais elle était où cette mémoire ? Car cette mémoire faussement occupée empêchait de conserver en cache de gros fichiers (j’ai vérifié).

      Alors on pourrait se dire qu’avec autant de mémoire on s’en moque un peu si Firefox et ce genre d’appli s’étale. Sauf que non, s’il se met à bouffer 64 ou 128Go sur un système parce qu’il se sent à l’aise, il ne sera pas possible de conserver en cache disque de très gros fichiers ni beaucoup de fichiers, et donc les activités de production qui traitent de gros fichiers vont devoir lire le disque dur au lieu du cache mémoire, tout ça parce que t’as un Firefox en arrière plan avec des onglets sur des sites web 2.360™ de märde avec scrolling infini.

      BREF, j’ai pas encore identifié tout ce qui fait qu’un système s’étale, mais clairement, la consommation de RAM augmente avec la RAM disponible, et pas forcément comme on le voudrait. Et quand les applications s’étalent parce qu’elles se disent « c’est bon ça va je peux », elles peuvent manger la mémoire que l’on destine à d’autres usages… par exemple le cache disque qui se retrouve invalidé par tout et n’importe quoi.

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Pas de swap … pas de problème

        Posté par  . Évalué à 3 (+1/-0).

        Je ne comprends pas ton problème. Comment se présente :

        Saturer, peut-être pas, mais quelque soit la taille de ta mémoire, tu pourras toujours avoir des trucs qui l’occupent au détriment de ce dont tu as besoin.

        J'utilise pas mal de softs réputés très consommateurs (firefox, intellij - souvent 2 instances -, 3 ou 4 applications electrons, chromium, divers logiciels en java) et je ne ressens jamais de problème.

        Quand je regarde (c'est pas fréquent), je suis entre 50 et 60% d'occupation par mes appli et le reste qui est pris en cache. Je n'ai aucune configuration particulière et 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.

        Alors j’ai essayé plus de trucs.

        Tu peux peut être passer par des cgroups pour limiter la mémoire.
        https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory

        • [^] # Re: Pas de swap … pas de problème

          Posté par  (site Web personnel) . Évalué à 5 (+3/-1).

          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.

          Souvent quand je travaille sur beaucoup de données, je fais quelque chose comme ça (dans le dossier contenant les données) :

          # astuce: remplacer 4 par un nombre précisément adapté au stockage,
          # ici 4 est donné comme exemple pour un RAID10 qui peut lire 4 fichiers en parallèle à la vitesse nominale de 4 disques durs.
          find . -type f -print0 | parallel --will-cite --bar -0 -I{} -P4 dd if={} of=/dev/null bs=10M status=none
          

          Cette commande va tout simplement lire tous les fichiers entièrement et donc les charger en cache disque.

          Une fois ceci fait, toute lecture sera extrêmement rapide, un programme peut lire un fichier de 100Go à plusieurs Go/s. Il est aussi possible de faire ce genre de dd pour charger le fichier suivant pendant que le précédent est en train d’être traité, etc.

          Avec un Firefox qui s’étale en prenant toute la place qu’il croit pouvoir prendre, les gros fichiers en cache mémoire se font virer du cache et sont alors lus depuis le stockage qui peut être plusieurs fois plus lent (disque mécanique par exemple !). Quand je travaille sur des images, vidéo ou du son je produit souvent des fichiers intermédiaires en sans-perte et peu compressé, mais le temps gagné à utiliser un codec qui compresse peu peut être perdu plusieurs fois si à chaque lecture du fichier produit la bande passante de lecture est celle d’un disque dur parce que Firefox en arrière plan a quelques onglets sur un réseau social à scrolling infini…

          Mettre des fichiers volontairement en cache mémoire est une stratégie très efficace. J’ai d’ailleurs parfois fait ça sur des serveurs par exemple : précharger les profils utilisateurs pour accélérer l’ouverture de session, j’ai parfois augmenté la ram de certains serveurs pour cette seule raison : pouvoir conserver tous les profils utilisateurs en ram.

          Alors si un développeur d’une appli ou service utilisé sur le même serveur a décidé qu’il allait sonder la mémoire pour décider de l’occuper pour son bébé sans m’en parler, je suis pas vraiment d’accord. Je n’achète pas de la ram pour lui.

          Pour continuer sur l’exemple initial, je n’achète pas de la ram pour que Firefox puisse conserver tout ce que peut afficher le scrolling infini de Facebook.

          Linux propose des outils très pratique pour rendre certaines opérations très rapide (copie-sur-écriture avec btrfs, cache disque…):

          $ du -shc */*blabla* | tail -n 1
          149G    total
          
          $ time cp -a --reflink */*blabla* process/
          real    0m5,546s
          user    0m0,000s
          sys 0m5,541s
          
          $ ls process | wc -l
          27
          
          $ echo 3 | sudo dd of=/proc/sys/vm/drop_caches status=none
          
          $ time find process -type f -print0 | parallel --will-cite --bar -0 -I{} -P4 dd if={} of=/dev/null bs=10M status=none
          100% 27:0=0s process/blabla
          
          real    5m28,149s
          user    0m0,902s
          sys 1m43,974s
          
          $ time find process -type f -print0 | parallel --will-cite --bar -0 -I{} -P4 dd if={} of=/dev/null bs=10M status=none
          100% 27:0=0s process/blabla
          
          real    0m5,193s
          user    0m0,201s
          sys 0m15,826s
          

          Interprétation : dans cet exemple j’ai environ 150Go de données à traiter en 27 fichiers (dans cet exemple réel, les fichiers font entre 1 et 22Go chacun). Grâce à btrfs je peux les copier dans un dossier de travail en 5s (copie sur écriture). Si le cache disque est vide (cas suboptimal), lire ces données prendra 5 minutes et demi (sachant que c’est possiblement séquentiel et donc déjà optimal), mettre ces données en cache disque prendra donc 5 minutes et demi. Mais, une fois ces données dans le cache disque, les lire ne prendra que 5s. Lire 150Go en 5s c’est une vitesse de lecture de 30Go par seconde. Il peut être donc très intéressant de précharger des fichiers en cache disque si une application doit les lire plusieurs fois et/ou de manière plus ou moins aléatoire, et ce serait vraiment dommage qu’un onglet de Firefox chargeant le prochain lolcat à la mode réclame d’éjecter du cache un gros fichier de 20Go, en plus mon petit doigt me dit que Linux pourrait précisément choisir d’éjecter le plus gros… 🤦‍♀️️

          Parmi les astuces dans mon couteau suisse, j’ai aussi ceci :

          $ killall -STOP firefox
          → faire des opérations gourmandes en CPU, ram et IO.
          $ killall -CONT firefox
          

          La première commande va suspendre tous les processus Firefox (comme si j’avais fait Ctrl+Z sur chacun d’eux), à lancer avant de faire des opérations gourmandes en calcul, mémoire et entrées/sorties quand Firefox est en arrière plan. La seconde commande va les réveiller (comme si j’avais fait fg sur chacun d’eux), à faire quand on a besoin à nouveau de visiter le web. En plus il est possible que puisque les processus dorment, le noyau décide de les déplacer vers le swap pendant que l’on précharge en cache disque les gros fichiers ! C’est tout bénéf !

          Accessoirement j’ai écrit un script que j’utilise pour suspendre Firefox quand je verrouille ma session et le réveiller quand je déverrouille ma session, comme ça Firefox cesse de faire du réseau, de faire chauffer le CPU et de gratter le disque dur pendant que j’ai le dos tourné, tout en conservant certains calculs en tâche de fond. C’est une forme de « mise en veille partielle ».

          Quand je dois laisser l’ordinateur traiter des données mais que ce n’est pas gourmand, le script suspend certains programmes, met le processeur et les cartes graphiques en économie d’énergie, désactive des cœurs… mais tourne toujours pour traiter ci ou ça ou servir tel ou tel service.

          Je rêve d’une application façon « gestionnaire de tâche » qui me permettrait en deux clic de suspendre telle ou telle application et de la déplacer dans le swap, pour laisser toute la place à autre chose. Si quelqu’un connaît un moyen de dire au noyau de déplacer une application donnée dans le swap, je suis preneur (sachant que si elle est suspendue, on sait déjà qu’elle n’en sortira pas toute seule).

          Le cache disque est un super outil quand on commence à l’utiliser intentionnellement, d’ailleurs j’ai remarqué que certaines applications comme Kdenlive font des xrun dans les premières secondes de lecture quand on déplace le curseur de lecture, et je me demande si on pourrait réduire simplement ces xrun si Kdenlive commençait à précharger le morceau de fichier qui va suivre (à la manière d’un basique dd) dès le positionnement du curseur. Entre le moment où l’utilisateur positionne le curseur et le moment où l’utilisateur lance la lecture il peut se passer 1/4 de seconde étant donné les réflexes humains, et ça peut être suffisant pour précharger assez pour éviter les micro-coupures audio, qui sait ?

          Tu peux peut être passer par des cgroups pour limiter la mémoire.
          https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory

          Merci, je vais regarder ça ! =)

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: Pas de swap … pas de problème

            Posté par  . Évalué à 2 (+0/-0).

            Ah oui tu utilise le cache disque comme ça. Je connais l'intérêt, même si je m'en suis jamais servi. Pourquoi tu n'utilise pas vmtouch pour ça ?

            Mes données sont plus grosses que mon disque, je les récupère en réseau donc c'est pas un problème que je vois.

            C'est combien de fois plus long d'envoyer ces données vers une partition tmpfs en guise de chargement ?

            Le cache disque est un super outil quand on commence à l’utiliser intentionnellement,[…]

            Ce n'est pas l'impression que j'ai, c'est très fragile comme technique et ça consiste à gérer l'état de l'ensemble de la machine pour que ça marche. Tu peux flinguer tout ton chargement juste avec un grep récursif par exemple.

            En échouant à trouver la doc linux du cache pour savoir si c'était ou non de l'ordre du hack. Je suis tombé sur ça qui pourrait être intéressant.
            https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/cache.html

            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.

            • [^] # Re: Pas de swap … pas de problème

              Posté par  (site Web personnel) . Évalué à 5 (+3/-1). Dernière modification le 18/06/22 à 15:40.

              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.

              En échouant à trouver la doc linux du cache pour savoir si c'était ou non de l'ordre du hack. Je suis tombé sur ça qui pourrait être intéressant.
              https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/cache.html

              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.

              Le ticket est toujours ouvert. Le dernier commentaire d’il y a trois ans dit:

              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  . Évalué à 3 (+1/-0).

                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 ?

                Personne ne dit le contraire et quand tu travail sur ce genre de chose, tu essaie d'avoir des gains pour le plus grand nombre. Si je prend le premier exemple que je vois pour des config orientées jeux vidéo (donc relativement performante) : https://www.canardpc.com/les-configs-de-canard/

                Dépasser 16Gio ne semble pas être une priorité, mais oui c'est un cas et on peut trouver des tas d'utilisations qui vont demander 32Gio et plus. Mais je ne suis pas sûr que ce soit les cas d'utilisation de FF les plus classiques (ils ont une télémétrie pour savoir ça).

                le programme agit comme s’il était tout seul

                Non c'est clairement pas ce que je vois de firefox, il s'adapte à ce qu'il voit. Tu utilise une fonctionnalité qui passe sous les radar et je suis convaincu que c'est une fonctionnalité explicitement en besteffort. Du coup oui ça gratte.

                • [^] # Re: Pas de swap … pas de problème

                  Posté par  (site Web personnel) . Évalué à 5 (+3/-1).

                  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.

                  Si je prend le premier exemple que je vois pour des config orientées jeux vidéo (donc relativement performante) : https://www.canardpc.com/les-configs-de-canard/

                  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  . Évalué à 3 (+2/-1).

                    Je vais réexprimer ma thèse qui n'était pas claire. Non Firefox n'est pas optimale dans toutes les circonstances et le fait de lui demander de suivre les évolutions du web ne l'aide pas à être économe. Aujourd'hui il n'existe pas d'implémentation de HTML5, CSS3 et ES2022 véritablement plus économe que ça. Depuis 10 ans Firefox perds des utilisateurs pour cette raison donc oui ils priorisent ça. Multiplier les exemples n'en fait pas des arguments pour autant.

                    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.

                    Ça n'est pas ce que j'observe. J'ai 32Gi de ram, 36 de swap, je lance Firefox avec des dizaines d'onglets, 4 ou 5 applications electron, intellij, cassandra ponctuellement, memory analyser,… Sans rencontrer de problèmes particuliers.

                    Cassandra en production a besoin d'un cache disque contrôlé donc on le lance sur des machines qui ne font que ça. Sur une machine utilisateur reposer sur ce cache disque n'est pas fiable n'importe quel outil peut rendre tout ça inopérant.

                    Pour moi la solution a "ma mémoire se fait déloger par une application" c'est "je vais réserver la mémoire dont j'ai besoin".

              • [^] # Re: Pas de swap … pas de problème

                Posté par  (site Web personnel) . Évalué à 3 (+1/-0). Dernière modification le 18/06/22 à 16:13.

                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

                En tout cas, après quelques heures d'utilisation assez intensive de ma machine avec 4go ram et 12Go swap, il semble bien que limiter la quantité de mémoire allouée au cache de firefox ait un effet très positif sur la réactivité globale du système.

                … 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 …

                Alors, justement, parlons de la récupération dex onglets. J'ai déja eu deux ou trois crashes (coupure électrique ou plantage dur) qui m'ont perdu la liste des onglets, et à chaque fois, pour moi ça a été le drâââme. Il y a quoi comme remède, genre une extension qui permette d'enregistrer la liste des tabs dans un fichier texte ?

      • [^] # Re: Pas de swap … pas de problème

        Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

        Et puis j’ai découvert la clé Firefox browser.cache.memory.capacity qui détermine le cache en mémoire vive de Firefox. Par défaut elle est mise à -1 ça veut dire, pas de limite haute !

        Over9000 !

        J’ai mis la limite browser.cache.memory.capacity à 2000000 pour 2Go de cache en mémoire, ce qui le plafonne…

        Ah, grand merci. Je pense que tu viens de me donner l'explication d'un truc qui me tracassais depuis quelques semaines : J'ai deux machines assez semblables : 64 bits, 4 Go, même Debian, même Firefox. Et Firefox gonflait bien plus sur une que sur l'autre. Pourquoi ?

        C'est en lisant ton message que j'ai compris : l'une des machines a juste 1 Go de swap, alors que l'autre en a 12 ! J'ai donc limité la capacity à 1000000 des deux cotés, et pour le moment, le gonflement semble maitrisé. On verra à l'usage dans le temps…

        • [^] # Re: Pas de swap … pas de problème

          Posté par  (site Web personnel) . Évalué à 6 (+3/-0). Dernière modification le 18/06/22 à 04:09.

          Ah oui en effet, je confirme ton impression ! J’avais remarqué un truc (c’est un sentiment, pas mesuré, mais franchement très sensible) c’est que Firefox semblait consommer la mémoire en fonction du swap disponible. Donc imagines tu as 32Go de ram, tu veux pouvoir suspendre même si les 32 Go de ram sont plein et que tu swappes déjà ? T’as un gros swap de 64Go ? Ma sensation c’est que Firefox réagit comme s’il y avait 96 Go de ram et se met à l’aise et en laisse partout. Alors si tu utilises zram au lieu de zswap et que tu as plein de cœurs, tout d’un coup tu vas avoir des centaines de Go de swap (qui en fait n’existent pas !) !!!! Et Firefox va prendre encore plus de place !

          Sinon dans les applications qui gonflent, qui gonflent, j’ai remarqué nautilus aussi. C’est probablement lié aux vignettes (thumbnails), mais je ne sais pas si ça monte toujours et toujours dans tous les cas où si comme Firefox il se le permet en fonction de ce qu’il suppose être de la ram disponible. Mais sur la machine avec des centaines de Go de ram il n’est pas rare que je vois nautilus manger de la mémoire dans l’ordre de la dizaine de Go après quelques semaines…

          ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Pas de swap … pas de problème

        Posté par  (site Web personnel) . Évalué à 2 (+1/-0).

        echo 90 > /proc/sys/vm/swappiness et tout ce qui traîne trop longtemps sans servir dans la RAM va dans le swap et libère de la place pour les applis qui en ont vraiment besoin

  • # Firmware privateur

    Posté par  . Évalué à 3 (+2/-0).

    Aucun rapport, mais j'ai lu en diagonale ton article:

    Pendant l'installation, il m'a été demandé de charger le firmware rtl_nic/rtl8168e-3.fw. Il s'agit d'un firmware non-libre pour la puce réseau Realtek RTL8111E. Je ne l'avais pas mais, étonnement, cela n'a pas empêché l'installation de se poursuivre, le système téléchargeant malgré tout les paquets dont il avait besoin (pour information, vous trouverez ce firmware au sein du paquet firmware-realtek). Étrange.

    Donc la carte réseau fonctionne sans le firmware privateur ? Qu'apporte son installation ?

  • # inclure le module lz4 dans initramfs

    Posté par  . Évalué à 2 (+1/-0).

    Il faut ajouter les modules de compression dans l'initramfs pour pouvoir les charger avant l'activation
    (ou bien activer zswap plus tard)

    $ tail -8 /etc/initramfs-tools/modules 
    #   in case we want to change zswap compression algorithm
    lz4hc
    lz4hc_compress
    lz4
    lz4_compress
    # and memory allocator
    z3fold
    
    • [^] # Re: inclure le module lz4 dans initramfs

      Posté par  (site Web personnel) . Évalué à 3 (+0/-0). Dernière modification le 15/06/22 à 20:45.

      Oui, merci, mais je crois que je l'ai fait en suivant le tuto du lien donné https://baronhk.wordpress.com/2021/10/03/setting-up-zswap-in-debian-11-gnu-linux/ :

      sudo nano /etc/initramfs-tools/modules
      Add the word z3fold to the end and then press Ctrl+O to save and then Ctrl+X to exit.
      Run update-initramfs -u as the administrator.
      sudo update-initramfs -u

      Et pourtant !

      • [^] # Re: inclure le module lz4 dans initramfs

        Posté par  . Évalué à 2 (+1/-0).

        [ 0.376491] zswap: compressor lz4 not available, using default lzo
        [ 0.379879] zswap: loaded using pool lzo/z3fold
        

        Oui, le module z3fold est bien trouvé, il te manque lz4 à rajouter sur une ligne à la suite
        de z3fold dans /etc/initramfs-tools/modules

        • [^] # Re: inclure le module lz4 dans initramfs

          Posté par  (site Web personnel) . Évalué à 3 (+0/-0).

          Ha oui, ça marche du coup, merci !

          J'ai ajouté lz4 et lz4_compress, puis
          sudo update-initramfs -u et redémarrage et c'est tout bon

          $ sudo dmesg | grep zswap
          [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.18.0-1-amd64 root=UUID=55a67d5b-ea0a-451a-9cbb-1cfcb178dee1 ro quiet zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=25 zswap.zpool=z3fold
          [ 0.022413] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.18.0-1-amd64 root=UUID=55a67d5b-ea0a-451a-9cbb-1cfcb178dee1 ro quiet zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=25 zswap.zpool=z3fold
          [ 0.407787] zswap: loaded using pool lz4/z3fold

          et

          $ grep -R . /sys/module/zswap/parameters
          /sys/module/zswap/parameters/same_filled_pages_enabled:Y
          /sys/module/zswap/parameters/enabled:Y
          /sys/module/zswap/parameters/max_pool_percent:25
          /sys/module/zswap/parameters/compressor:lz4
          /sys/module/zswap/parameters/non_same_filled_pages_enabled:Y
          /sys/module/zswap/parameters/zpool:z3fold
          /sys/module/zswap/parameters/accept_threshold_percent:90

  • # Trop d'onglets ouverts dans Firefox !

    Posté par  . Évalué à 3 (+2/-1).

    Le combat est il définitivement perdu ?

    ;)

  • # J'en ai fait un billet pour avoir la méthode sur Debian

    Posté par  (site Web personnel) . Évalué à 5 (+2/-0).

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.