Forum Linux.général purger le cache RAM après archivage et zippage de gros dossiers

Posté par . Licence CC by-sa
0
26
août
2016

Bonjour,

Par manque d'inode sur un FS je vais devoir archiver beaucoup de dossiers sur un autre FS.
J'aimerai savoir si il y a un commande que je peux intégrer dans ma boucle pour purger le cache après à chaque tour de boucle car la RAM sature après la copie d'environ 300 dossiers et fait planter l'opération en cours de route?

Voici à quoi ressemble ma boucle

for dir in $dirsrc/* ; do

 if [ -d $dir]; then
    ionice -c 2  tar -cvf - $dir | throttle -M 10 | gzip > $dirdst/$dir.tar.gz
    if [ $? -eq 0]; then
        ionice -c 2 rm -rf $dir
    fi
fi

Merci beaucoup

  • # sync ?

    Posté par . Évalué à 2. Dernière modification le 26/08/16 à 14:47.

    pas certain que ce soit ce que tu cherches, mais "sync" est bloquant, et attend jusqu'à ce que toutes les écritures soit faites.

    • [^] # Re: sync ?

      Posté par . Évalué à 0.

      Bonjour gUI,

      Et comment puis-je utiliser sync ou autrement dit suis-je sur qu'après le tar | gzip le fichier est bien écrit?
      Car j'ai lu sur sync qu'il fallait être sur que les données soient ecrites sur disk avant d'utiliser sync.

      Donc si je fais ça
      tar -zcvf $dir | throttle -M 10 | gzip > $dirdst/$dir.tar.gz && sync
      est-ce bon ?

      Merci, je sais que ce que je dis n'est pas très clair mais c'est un peu le bordel dans ma tête.

      • [^] # Re: sync ?

        Posté par . Évalué à 2. Dernière modification le 26/08/16 à 15:43.

        attention tu mixes 2 commandes :)

        tar cvf machine > destination

        et

        tar zcvf destination machin

        donc déjà ça ne va pas marcher (il manque la destination à la première commande; et ensuite tu gzip 2 fois (z) ;)

        et je ne vois toujours pas l'intérêt de throttle mais je n'ai pas toutes les infos ;)

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: sync ?

        Posté par . Évalué à 3.

        Car j'ai lu sur sync qu'il fallait être sur que les données soient ecrites sur disk avant d'utiliser sync.

        Bin non justement, sync sert à forcer l'écriture.

        Exemple.

        Tu as un clé USB lente. Tu copies dessus 1GB. Ca met 10 secondes. Tu te dis "pas possible en 10 secondes, tout n'est pas écrit". Et en effet, tu vois ta clé clignoter. Mais la commande 'cp' est finie, tu es de nouveau au prompt.
        Tu peux taper 'sync'. Et là la commande va mettre plusieurs minutes à te rendre la main. Parce que elle attend que les données soient réellement écrites (celles de la clé USB, et au passage toutes les autres de l'ordi, quel que soit le périphérique).

        D'ailleurs une fois que la commande sync est finie, tu peux arracher la clé USB sans umounter. C'est pas spécialement conseillé (ni très intelligent) mais ça marchera : tu es certain que toutes les données de la clé sont écrites, ta clé est "propre".

        Autre exemple : quand le kernel s'éteint, il lance rapidement un "sync" lui-même afin de forcer tous les caches à se vider et de pouvoir éteindre proprement la machine.

        tar -zcvf $dir | throttle -M 10 | gzip > $dirdst/$dir.tar.gz && sync

        Oui, je pense à ça en effet. Dans ta commande principale, tu ajoutes un 'sync' à la fin.

  • # limit inode

    Posté par (page perso) . Évalué à 2.

    Par manque d'inode sur un FS je vais devoir archiver beaucoup de dossiers sur un autre FS.

    Jamais eu le cas malgré des gros volumes pleins d'images ou de courriels IMAP… Mes volumes sont tous en XFS.

    • [^] # Re: limit inode

      Posté par . Évalué à 1.

      Là les volumes sont en EXT3 et il y a plein de petits fichiers jpeg et texte (+ de 60 millions)

  • # curieux

    Posté par . Évalué à 2.

    j'ai un doute sur l'utilité di throttle, tant que tu ne joues pas sur le réseau, ça ne devrait pas trop poser de problèmes, j'ajouterai que ta commande joue avec 3 pipe | throttle | (je considère throttle comme un pipe), là ou un tar zcvf $dirdst/$dir.tar.gz $dir suffirait (mais on a pas le throttle; mais là encore si c'est pour la capacité de destination, il n'est pas au bon endroit
    tar zcvf $dir | throttle -M 10 > $dirdst/$dir.tar.gz

    Et si c'est tar qui n'a pas l'option z, tar cvf $dir | gzip | throttle -M10

    enfin j'aurais tendance à préférer l'usage de la commande tout en un (tar zcvf ) pour la simple et bonne raison que

    true | true | false
    va donner un $? à faux
    alors que
    false | true | true
    va donner un $? à vrai, or le tar aura foiré (incomplet).

    Quant au cache, je ne vois pas trop duquel tu parles, si c'est celui qui est affiché par la commande free, c'est normal qu'il soit plein, et ça ne fait pas planter la machine.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: curieux

      Posté par . Évalué à 1.

      En fait, la destination est un volume nfs , c'est pourquoi j'ai mis throttle -M10.
      Maintenant c'est vrai que de faire un test à l'issue de ma commande c'est pas super intelligent de ma part étant donné que c'est une succession de 3 commande et que je pense en effet qu'il va évaluer uniquement le retour de la dernière commande.

      maintenant je sais pas trop comment faire pour tester ET que le fichier est bien présent à la destination ( if [ -e $dirdst/$dir.tar.gz ] ) Et que l'archive est bien complète?

      Pour le cache en fait c'est pas vraiment le cache mais la consommation RAM elle même qui augmente au bout de 2 ou 3 heures.
      Sachant qua ça fait 3 jours que j'essaye de faire la copie mais que ça plante chaque fois à un endroit différent.

      • [^] # Re: curieux

        Posté par . Évalué à 2. Dernière modification le 26/08/16 à 16:17.

        dans ce cas il faut le mettre au dernier moment avec le minimum de |

        typiquement tar zcvf - $dir | throttle -M10 > $destdir/dir.tar.gz

        histoire de compresser dès le début et avoir le throttle sur le flux réel et pas avant compression; mais là encore on a aucune garantie que le tar s'est bien déroulé

        si tu peux écrire le fichier en local (quitte à monter un volume en loop ou sur un disque temporaire), tu peux créer le fichier en local puis le déplacer sur le volume distant, de préférence avec rsync sans passer par le nfs

        tar zcvf /chemin/temporaire/${dir}.tar.gz $dir && rsync -e ssh --remove-sent-files  --bwlimit=KBPS /chemin/temporaire/${dir}.tar.gz user@seveurNFS:/chemin/destination/sur/le/serveur 
        
        # au pire tu peux aussi donner le chemin destination remplacer 
        user@seveurNFS:/chemin/destination/sur/le/serveur par  $destdir/${dir}.tar.gz,

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: curieux

          Posté par . Évalué à 2. Dernière modification le 26/08/16 à 23:47.

          Je conseillerais aussi rsync pour cela. De même, j'appuye le fait que le cache ne peut pas causer une pénurie de mémoire, donc vouloir le vider est une mauvaise idée (sinon c'est echo 3 > /proc/sys/vm/drop_caches…). Peut-être qu'ajouter de la swap pourrait résoudre ton problème ?

          Concernant throttle, son utilisation est largement douteuse. Cela n'est pas parcequ'un process écrit à une certaine vitesse que le noyau va être plus ou moins chargé, va cacher plus ou moins, etc… Il faut garder en mémoire que pour ne pas exhiber des performances désastreuses, un FS combine les écritures de plusieurs activités en même temps.

          Pour tester les conditions dans un pipe, apparemment bash possède l'option pipefail (set -o pipefail) qui fait l'affaire. Sinon, tu pourrais passer par un named-pipe, et tu lances tar en dernier. Genre mkfifo /tmp/fifo; gzip > out.gz < /tmp/fifo; tar cf - > /tmp/fifo.

          De manière plus générale, je te conseillerais de rechercher la cause de l'erreur que tu rencontres, éventuellement en postant ici, au lieu de jouer à l'apprenti-sorcier. Car en prenant l'habitude d'essayer un truc au pif au lieu d'essayer de comprendre ce qui ne va pas, tu ne parviendras jamais à produire un système fiable.

          edit: je m'adresse bien sûr à la deuxième personne à l'auteur de ce sujet.

          • [^] # Re: curieux

            Posté par . Évalué à 1.

            Pour l'astuce du fifo afin de tester le retour de toutes les commandes, on peut faire:

            run_cmd() {
              retfile=$1
              shift
              $*
              echo $? > $retfile
            }
            
            mkfifo gzipin
            run_cmd /tmp/ret1 gzip  < gzipin > out.tar.gz &
            run_cmd /tmp/ret2 tar -cf .. > gzipin
            
            r1=`cat /tmp/ret1`
            r2=`cat /tmp/ret2`
            
            if [ $r1 -eq 0 -a $r2 -eq 0 ]; then ... ; fi

            Sh étant ce qu'il est, il n'y a pas vraiment d'autre moyen que de passer par un fichier pour stocker les codes retours…

          • [^] # Re: curieux

            Posté par . Évalué à 1. Dernière modification le 27/08/16 à 00:08.

            mkfifo /tmp/fifo; gzip > out.gz < /tmp/fifo; tar cf - > /tmp/fifo

            Il manque un '&' dans l'appel à gzip, sinon il ne va pas se passer grand chose :p

            mkfifo /tmp/fifo
            gzip > out.gz < /tmp/fifo &
            tar cf - > /tmp/fifo

  • # d'autres pistes

    Posté par . Évalué à 2.

    tu peux essayer aussi

    tar cvf $dirlocal | ssh machinedistance tar xv -C /dossier/destination

    qui ne compresse pas par clone le dossier $dirlocal dans le /dossier/destination de la machine distante.

    mais evidemment si tu as ssh entre les machines, un bon rsync devrait faire le boulot.

    rsync -aP $dir machinedistante:/dossier/destination

Suivre le flux des commentaires

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