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 ?
[^] # 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.
Souvent quand je travaille sur beaucoup de données, je fais quelque chose comme ça (dans le dossier contenant les données) :
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
ddpour 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...):
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 :
La première commande va suspendre tous les processus Firefox (comme si j’avais fait
Ctrl+Zsur 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 faitfgsur 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 ?Merci, je vais regarder ça ! =)
ce commentaire est sous licence cc by 4 et précédentes