Forum Linux.débutant ionice et nice

Posté par . Licence CC by-sa
Tags :
2
16
mar.
2014

Bonjour à tous,

Il m'arrive de regarder un film pendant une très grosse copie via le port USB (typiquement une copie via USB d'un répertoire comportant des centaines de gros MKV de 10 GB chacun). Il arrive également que mes rsync automatiques de backup FULL et INC s'activent pendant cette copie.

La lecture d'un MKV, pendant une seule copie (sans rsync de backup) suffit à bloquer parfois la lecture du MKV. Je veux dire que parfois, genre toutes les 15 secondes, le son continue mais l'image se fige pendant 3 secondes.

J'ai tenté de jouer sur ionice et nice pour donner moins de priorité aux rsync et à la copie via USB, j'ai même tenté de donner plus d'importance à VLC (renice avec une priorité -5), mais rien n'y fait. Ma configuration matérielle et logicielle est : Core i7 860, 8 Go de RAM, SSD de 128 Go pour le système Arch GNU/Linux 3.13.6-1-ARCH #1 SMP PREEMPT (à jour), donnés sur tableau RAID 5 de 3*1TB.

Voici l'un de mes scripts de backup INCR :

    [root@zoulou bin]# cat backup_DOC_incr.sh 
    #!/bin/sh

    source=/home/bastien/DOCUMENTS
    destination=/media/RAID_5/BACKUP_DOC_INCR

    echo "===========================================================================================================================";
    echo "===>> rdiff-backup process will now start";
    echo "===========================================================================================================================";
    nice --adjustment=19 ionice --class 3 rdiff-backup $source $destination

    echo "===========================================================================================================================";
    echo "===>> Removing backups older than 2 weeks";
    echo "===========================================================================================================================";
    nice --adjustment=19 ionice --class 3 rdiff-backup --force --remove-older-than 2W $destination

    nice --adjustment=19 ionice --class 3 sync
    [root@zoulou bin]# 

Pour la copie via USB, je fais un cp et modifie les gentillesses avec renice et ionice.

Pour le "sync" en dernière ligne du script ci-dessus, qu'en pensez-vous ?
Faut-il mettre nice avant ou après ionice ou ça n'a pas d'importance ?

Auriez-vous une idée de comment faire ?

EDIT : BUG !!!! au lieu de `{mathjax} source il faudrait lire $source . Je vais signaler le bug aux admins Linuxfr.
NdM: le passage du bloc de code en coloration syntaxique bash masque le problème. Bug déclaré dans le suivi

  • # Précisions

    Posté par . Évalué à 1.

    Re moi,

    J'aurais peut être dû préciser que tous mes disques sont chiffrés :

    • SSD /
    • tableau RAID 5 composé de 3 disques
    • HDD externe de 3 TB

    Ca génère forcément un peu de calcul. Mais pas de quoi figer ainsi le système je suppose.

    Je précise également que ces figeages se produisent même sans VLC : là, j'utilise uniquement Firefox sous XFCE et ai lancé une copie (cette fois-ci via Thunar) et le système freeze toutes les 10 secondes environ.

    • [^] # Re: Précisions

      Posté par . Évalué à 3.

      toutes les 10sec, ce serait un flush de buffer,
      tu as essayé sur un autre port USB ?
      tu as essayé sur autre chose qu'un port USB (disque à disque interne ?)

      • [^] # Re: Précisions

        Posté par . Évalué à 1.

        Entre mon SSD / et mon autre SSD $HOME/DOCUMENTS ou mon tableau RAID5 HDD, je fais souvent des transferts : ça turbine vraiment à fond et je n'ai aucun ralentissement. Ce n'est que par le port USB que ça ralenti tout. J'ai tenté depuis un port USB 2.0, donc avec un débit de 25 Mo/s, et ça ralenti également tout aussi fortement le système.

        Vous n'allez quand même pas me conseiller les cgroups ? :-)

        Merci…

        • [^] # Re: Précisions

          Posté par . Évalué à 1.

          Hello,

          Juste pour préciser que selon le port USB que j'utilise, le problème se pose, ou pas.
          Ma carte mère est équipé d'une puce pour partager la bande-passante d'un bus entre un chipset USB et un chipset SATA3.
          Je penche que ça vient de là.

          Voilà, c'était juste pour apporter cette précision, au cas où d'autres personnes rencontre ce genre de problème.

          En se branchant sur le bon port USB, il n'y a plus de problème.

          +

  • # Ca ne m'étonne pas

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

    J'ai déjà remarqué ce genre de choses sur plusieurs OS: une forte utilisation des entrées/sorties ralentit fortement le système.

    Je ne suis pas du tout compétent en la matière, mais j'ai fini par me dire que le problème doit se situer au niveau de l’architecture matérielle de nos machines et que donc le système n'y peut rien. Mais j'aimerais évidemment avoir une meilleure explication de la part de quelqu'un qui s'y connait vraiment.

    • [^] # Re: Ca ne m'étonne pas

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

      C'est normal, si tu fais un transfert assez coûteux en IO, la quantité d'interruptions sera élevé et le processeur les traitera assez prioritairement au détriment du reste du système.
      Sans compter que les bus de transferts peuvent être sur les bus d'autres périphériques où le système réside comme le disque dur ce qui affecte la réactivité du reste du système.

      • [^] # Re: Ca ne m'étonne pas

        Posté par . Évalué à 2.

        Hi,
        Y'a pas eu des solutions apportées pour ça, genre les canaux DMA ?
        Un simple transfert USB met un PC moderne à genoux ? Je n'arrive pas à croire que ce soit normal.

        • [^] # Re: Ca ne m'étonne pas

          Posté par . Évalué à 0.

          passe en USB3 ;)

          • [^] # Re: Ca ne m'étonne pas

            Posté par . Évalué à 3.

            Je suis en USB 3.0 et habituellement je fais tous mes transferts depuis un port USB 3.0.
            Cependant, là, pour voir si le problème se posait également en USB 2.0, j'ai branché sur un port USB 2.0.

            Conclusion, ça ne change rien j'ai exactement le même problème.

Suivre le flux des commentaires

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