Forum Linux.général MAO: Utilité d'un ramdisk / disque virtuel

Posté par  . Licence CC By‑SA.
Étiquettes :
5
10
juil.
2024

Je fais à mes heures perdues de la musique (de la MAO) sous Linux en utilisant un Raspberry Pi. En fait des Raspberry Pi: un Pi3B+ avec 1Gb de RAM, des Pi4B avec 2 ou 4Gb de RAM. D'une manière générale, je n'ai pas le sentiment qu'un manque de RAM se soit manifesté lors de mon utilisation courante, mais plutôt un manque de puissance de calcul lorsque l'on charge trop le système.

Par contre, il m'arrive de devoir "charger" "d'énormes" fichiers (plusieurs centaines de Mo). Cela peut être

  1. une soundfont qui va être utilisée par une seule application (fluidsynth ou linuxsampler par exemple). Voir par exemple https://www.pianobook.co.uk/

  2. une session, plus complexe, qui va peut être "lancer" plusieurs cas 1

Sur les Raspberry, le stockage se fait sur une carte SD aux accès en lecture assez lents comparés à un disque dur SSD par exemple.

Je me pose la question de l'utilité d'utiliser une part de la mémoire vive comme ramdisk pour y "précharger" ces énormes fichiers au démarrage de la machine et rendre ainsi le passage d'une configuration à une autre plus rapide.

Quoi qu'il en soit, le Pi doit pas mal mouliner (le Pi3B+ plus que le Pi4, lui même sans doute plus que le Pi5 -je n'en ai pas en ma possession-) pour arriver à ses fins lorsque je me retrouve à faire 1. ou 2.
J'ai du mal à savoir si c'est l'accès disque qui est en cause ou le CPU qui rame.

Je pense pouvoir me débrouiller pour mettre en place un tel système. En revanche je n'ai pas idée, à priori, du réel gain que cela pourrait apporter. Et à fortiori, à part chronométrer je ne sais pas comment évaluer la différence (j'entends par là des outils intégrés à Linux permettant d'obtenir une métrique fiable).

Si vous avez quelques idées ou pistes à suivre, je suis preneur.
Merci d'avance.

  • # Stockage externe

    Posté par  . Évalué à 6.

    Comme ça j'aurai tendance à mettre un petit SSD en USB (de 15 à 60€ pour 128Go à 1To) et laisser la RAM pour les traitements temps réel.

    Linux prendra de toutes façons toute la RAM disponible pour faire un cache disque avec, le noyau est vraiment très bon pour ça.

    • [^] # Re: Stockage externe

      Posté par  . Évalué à 1.

      J'utilise une carte SD pour l'OS, les applications et le stockage de mes soundfonts et de mes sessions.
      J'ai une petite clé USB discrète sut laquelle j'enregistre ma musique. Comme c'est pas souvent d'un intérêt énorme, j'efface régulièrement des fichiers.
      C'est parce que j'ai lu à droite à gauche que les cartes SD n'aimaient pas trop les cycles d'écritures/effacements qui pouvaient conduire à la corruption du support. (et du coup pas de swap non plus).

      C'est vrai que je pourrais déjà essayer de stocker mes gros fichiers de soundfonts sur la clé USB et voir si ça change quelque chose.

      "Si tous les cons volaient, il ferait nuit" F. Dard

      • [^] # Re: Stockage externe

        Posté par  . Évalué à 2.

        Attention, il y a clef usb et clef usb. Certaines sont aussi peu performantes qu'une carte SD.
        Un SSD sur USB c'est bien, mais ça vaudra pas un PC, le contrôleur de la Pi va sérieusement limiter les performances. Je crois que la Pi5 n'a pas ce problème.

        Je suis passé aux mini PC pour ça, marre d'acheter la nouvelle Pi, d'être déçu par les perfs, d'avoor à ajouter boîtier, alim, ventilo,…
        Un mini PC type Lenovo consomme environ 10W (vs 5W), alors à moins d'avoir besoin des GPIO.

  • # A prendre avec des pincettes...

    Posté par  . Évalué à 2.

    En tout logique, je laisse soins aux autres de me corriger, mais avoir les fichiers dans un ramdisk n'empêche pas le besoin de les charger en ram ensuite (à moins que l'application soit capable de gérer elle même le ramdisk). Donc si tu tentes l'expérience, tu risques d'avoir besoin du double de ram pour charger le fichier.

    Je suppose qu'un "free" te dira si ton système a suffisamment d'espace disponible pour vérifier ça avant de te lancer dans l'aventure.

    Pour ce qui est de la vérification de l'amélioration des perfs, il faut voir en fonction de ta manière de lancer et utiliser les soundfonts/projet. Une idée qui fonctionne pour certaines applications, c'est de la lancer et la fermer une fois qu'elle a terminé de charger. Ce n'est pas disponible sur beaucoup d'application par contre. Mais il doit y avoir moyen de vérifier en chargeant et regardant l'activité cpu/ram et en estimant qu'une charge faible pendant un certain laps de temps signifie que c'est terminé.

    Note que, si tu te plains des performances, vu la différence de rapidité entre un ramdisk et un carte sd sur le pi, je suppose que tu devrais rapidement voir une amélioration si tu dois en voir une.

    • [^] # Re: A prendre avec des pincettes...

      Posté par  . Évalué à 5.

      Une idée qui fonctionne pour certaines applications, c'est de la lancer et la fermer une fois qu'elle a terminé de charger.

      Si c'est pour forcer la mise en cache RAM, tu peux faire cat le_fichier > /dev/null, ça marche aussi :). Testé et approuvé pour un kiosque vidéo à une époque où le prix des SSD étaient prohibitifs.

      • [^] # Re: A prendre avec des pincettes...

        Posté par  . Évalué à 2.

        ça me surprend: si ça part dans /dev/null tu fais comment pour le retrouver ?

        "Si tous les cons volaient, il ferait nuit" F. Dard

        • [^] # Re: A prendre avec des pincettes...

          Posté par  . Évalué à 3.

          L'idée c'est que par exemple, tu as un fichier de 64 MB qui est prioritaire et à côté de ça 512 MB de cache.

          En faisant une première lecture (redirigée vers /dev/null), le fichier risque de se retrouver dans le cache. Si un peu après tu ré-essaie d'accéder au fichier en question, il y a des chances qu'il y soit encore.

          Par contre, ça ne risque pas de marcher si le fichier fait 8 GB pour un cache de 512 MB.

          Les vrais naviguent en -42

          • [^] # Re: A prendre avec des pincettes...

            Posté par  . Évalué à 1.

            histoire de compléter, avec un disque "classique" (pas SSD):

            sha256 sur un e-book de 6.7MB :

            3a6273fab7bed5d81b1c94ca3cc66712d9f1d20abebc0b68be9eda5456244d60  Jules Verne - Le Tour du monde en 80 jours - illustré.epub

real    0m0,979s
user    0m0,058s
sys 0m0,023s
3a6273fab7bed5d81b1c94ca3cc66712d9f1d20abebc0b68be9eda5456244d60  Jules Verne - Le Tour du monde en 80 jours - illustré.epub

real    0m0,042s
user    0m0,039s
sys 0m0,004s
3a6273fab7bed5d81b1c94ca3cc66712d9f1d20abebc0b68be9eda5456244d60  Jules Verne - Le Tour du monde en 80 jours - illustré.epub

real    0m0,043s
user    0m0,044s
sys 0m0,000s
3a6273fab7bed5d81b1c94ca3cc66712d9f1d20abebc0b68be9eda5456244d60  Jules Verne - Le Tour du monde en 80 jours - illustré.epub

real    0m0,034s
user    0m0,030s
sys 0m0,004s

            Sur un image iso de 628MB, c'est moins flagrant:

            23ab444503069d9ef681e3028016250289a33cc7bab079259b73100daee0af66  debian-12.2.0-amd64-netinst.iso

real    0m4,679s
user    0m2,960s
sys 0m0,196s
23ab444503069d9ef681e3028016250289a33cc7bab079259b73100daee0af66  debian-12.2.0-amd64-netinst.iso

real    0m2,983s
user    0m2,915s
sys 0m0,068s
23ab444503069d9ef681e3028016250289a33cc7bab079259b73100daee0af66  debian-12.2.0-amd64-netinst.iso

real    0m2,964s
user    0m2,900s
sys 0m0,064s
23ab444503069d9ef681e3028016250289a33cc7bab079259b73100daee0af66  debian-12.2.0-amd64-netinst.iso

real    0m2,954s
user    0m2,910s
sys 0m0,044s

            Les vrais naviguent en -42

          • [^] # Re: A prendre avec des pincettes...

            Posté par  . Évalué à 1.

            hmm, je regarde ça: https://docs.kernel.org/admin-guide/device-mapper/cache.html mais pour le moment je n'ai pas trop compris et finalement ce soir, j'ai un peu la flemme de m'y mettre.

            En tout cas merci du tuyau, c'est dans la TODO :)

            "Si tous les cons volaient, il ferait nuit" F. Dard

    • [^] # Re: A prendre avec des pincettes...

      Posté par  . Évalué à 1. Dernière modification le 10 juillet 2024 à 13:57.

      oui, free (j'utilise plutôt htop pour la vue d'ensemble "mémoire + charge CPU + applis gourmandes") n'indique pas de saturation de la mémoire.
      Le facteur limitant est le CPU selon mon expérience. Ainsi sur un Pi3, il y a certaines applications (des gros synthés comme SurgeXT ou des effet audio comme Aida-X par exemple) qu'il est tout simplement impossible d'utiliser.

      (l'application) la lancer et la fermer une fois qu'elle a terminé de charger

      Je ne comprends pas. Je veux m'en servir de l'appli, pas la fermer !

      "Si tous les cons volaient, il ferait nuit" F. Dard

      • [^] # Re: A prendre avec des pincettes...

        Posté par  . Évalué à 3. Dernière modification le 10 juillet 2024 à 14:29.

        On est plus vraiment dans le même cas de figure de choses à vérifier si c'est pour du surge ou du Aida-X. La question était surtout sur l'utilisation de ramdisk, l'utilisation cpu est peu impactée dans ce cas..

        Je me pose la question de l'utilité d'utiliser une part de la mémoire vive comme ramdisk pour y "précharger" ces énormes fichiers au démarrage de la machine et rendre ainsi le passage d'une configuration à une autre plus rapide.

        je ne sais pas comment évaluer la différence (j'entends par là des outils intégrés à Linux permettant d'obtenir une métrique fiable).

        Pour avoir quelque chose de fiable au niveau mesure il te faut un comportement reproductible. D'où ma proposition de charger l'application avec les données puis de la fermer. Tu vois le temps cpu et l'occupation mémoire avec et sans le ramdisk pour voir l'apport.

        Maintenant, tu peux bien entendu le faire manuellement, après tout c'est pour l'impression utilisateur qui prime :-)

  • # Essayer c'est simple...

    Posté par  (Mastodon) . Évalué à 3.

    Je pense pouvoir me débrouiller pour mettre en place un tel système. En revanche je n'ai pas idée, à priori, du réel gain que cela pourrait apporter.

    Je fais du traitement batch sur de gros fichiers, et je pose les fichiers intermédiaires dans /dev/shm le ramdisk extensible…

    Tu peux commencer à explorer cette piste, en surveillant quand même l'occupation de la mémoire.

    • [^] # Re: Essayer c'est simple...

      Posté par  . Évalué à 1.

      je ne connais pas trop ce /dev/shm (je sais juste que ça existe).
      Je pensais allouer 1Go des 4 du Pi4 à un disque virtuel de taille fixe donc (un truc que je savais faire il y a quelques années, donc je ne me fais pas trop de soucis sur ce point).

      Oui, tester, c'est approuver ou pas ! J'aurais peut être un peu de temps demain.

      "Si tous les cons volaient, il ferait nuit" F. Dard

      • [^] # Re: Essayer c'est simple...

        Posté par  (Mastodon) . Évalué à 3.

        je ne connais pas trop ce /dev/shm (je sais juste que ça existe).

        Je ne connais pas très bien le principe sous-jacent, mais ça s'utilise comme un répertoire classique, sauf que c'est en ram, et que donc ça ne touche pas le disque…

        Un exemple un peu synthétique :

        $ passeA source.tiff -o /dev/shm/$$.tiff
$ passeB /dev/shm/$$.tiff -o resultat.tiff
$ rm /dev/shm/$$.tiff

        Par contre, si tu remplis ta mémoire vive, l'excès va partir dans le swap, et là, ça va bien ralentir.

      • [^] # Re: Essayer c'est simple...

        Posté par  . Évalué à 2.

        Je l'avais oubliée celle-la … Je voulais tester son utilisation pour la compilation de gros projets … mais je n'ai pas eu le temps de le faire et ensuite je suis passé à autre chose.

  • # rpi4 avec boot sur USB/SSD voir sur NVME

    Posté par  . Évalué à 3.

    Perso j'ai acheté un boitier ARGON
    qui permet de mettre le RPI4 dans le boitier et d'avoir un header USB3/NVME

    comme ca je boote direct sur le NVME

    • [^] # Re: rpi4 avec boot sur USB/SSD voir sur NVME

      Posté par  . Évalué à 3.

      Perso j'ai renoncé aux raspberries ;-)
      Ça finit par coûter cher avec ce qu'il faut ajouter. Quand on voit le prix de mini pc d'occase …

      • [^] # Re: rpi4 avec boot sur USB/SSD voir sur NVME

        Posté par  . Évalué à 1.

        oui je suis assez d'accord, surtout en ce qui concerne le RBPi 5.

        Comme je suis déjà pas mal équipé, je fais avec ce que j'ai et essaye d'optimiser du coup. Car ils sont tous utilisés (+ou- intensivement) pour ce qu'ils offrent de plus important selon moi: les GPIO et les interfaces i2c, spi, uart qu'ils exposent (et le bon support logiciel par RaspberryPiOS en la matière contrairement à une BananaPi par ex).

        "Si tous les cons volaient, il ferait nuit" F. Dard

      • [^] # Re: rpi4 avec boot sur USB/SSD voir sur NVME

        Posté par  . Évalué à 3.

        Quand on voit le prix de mini pc d'occase …
        pour faire un serveur web/ssh en effet un mini PC sera rentable

        pour faire une domotique/robotique, qui va lire des bus SPI, I2C, etc ca peut etre comlpiqué avec un mini PC de base

Suivre le flux des commentaires

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