Ralentissement des performances lors de la copie de fichiers vers et depuis des périphériques USB


11

Lorsque je copie des fichiers vers et depuis des périphériques USB (appareil photo, disque dur, carte mémoire), mon système devient très lent. Par exemple, si je veux fermer une fenêtre, je déplace la souris mais cela prend environ 2 secondes ou plus avant que le curseur de la souris ne se déplace. Lorsque je place enfin le curseur sur le x et que je clique dessus, rien ne se passe pendant plus de 10 secondes. J'ai essayé cela avec tous les effets de bureau désactivés, mais le problème persiste.

Logiciel: Linux Mint 9 KDE Matériel:

  • Carte mère Asus SLI
  • NVidia 6600 GPU
  • 2 Go de RAM
  • Échange de 2 Go
  • AMD Athlox X2 @ 3800+

Pour moi, ce matériel ne devrait pas avoir de problèmes lors de l'exécution de ce logiciel et ce n'est pas le cas jusqu'à ce que je copie des fichiers via USB. Où dois-je commencer à chercher celui-ci? Je pense en quelque sorte que le pilote graphique peut être une partie du problème, mais je ne sais pas avec certitude.


2
vérifiez que les ports USB sont compatibles USB 2.0. certains ports USB, en particulier à l'avant des ordinateurs de bureau, n'étaient auparavant que des ports USB 1.0. Vérifiez également que les paramètres de votre BIOS sont optimaux pour les performances USB. Certains paramètres de vitesse USB et / ou paramètres USB hérités peuvent affecter vos performances.
Tim Kennedy

Le périphérique est-il formaté en NTFS? Si c'est le cas, j'essaierais de le reformater en FAT32 (ou EXT4 si vous prévoyez seulement de l'utiliser sur Linux).
RobinJ

3
Il semble y avoir un problème avec les pages énormes dans la gestion de la mémoire de Linux . Cela se produit rarement, mais on dirait que vous l'avez observé.
artistoex

@artistoex - Cet article résume complètement le comportement que je vivais. Dommage qu'il n'y ait pas de solution concrète. Quelqu'un sait si cela est corrigé dans les versions ultérieures? Temps pour une mise à niveau de toute façon.
John

comme le dit l'article, recompilez votre noyau avec la fonctionnalité transparente des pages énormes désactivée.
artistoex

Réponses:


7

Il semble y avoir un problème avec les pages énormes dans la gestion de la mémoire Linux . Cela se produit rarement, mais on dirait que vous l'avez observé.

Cause

Ceci est mon compte grossièrement simplifié de ce qui, selon l'article, se produit.

En cas de malchance, un processus se bloque au moment où il délivre un accès à la mémoire. En effet, lorsque des pages volumineuses transparentes sont activées, un accès à la mémoire peut déclencher un compactage synchrone (défragmentation de la mémoire principale), synchrone, ce qui signifie que l'accès à la mémoire ne se termine pas avant le compactage. Ce n'est pas en soi une mauvaise chose. Mais si l'écriture différée (par exemple des données mises en mémoire tampon sur USB) se produit en même temps, le compactage à son tour risque de s'arrêter, en attendant que l'écriture différée se termine.

Ainsi, tout processus pourrait finir par attendre qu'un périphérique lent termine l'écriture des données en mémoire tampon.

Guérir

La mise à niveau de la mémoire principale, comme l'a fait l'OP, peut aider à retarder le problème. Mais pour ceux qui ne considèrent pas cela comme une option, il existe deux solutions de contournement évidentes. Les deux impliquent la recompilation du noyau:

  • désactivation de la fonctionnalité transparente des pages immenses
  • appliquer le patch de Mel comme mentionné dans l' article

2

Cela ressemble à ma question ici (où une réponse m'a dirigé vers cette question):

/programming/10105203/how-can-i-limit-the-cache-used-by-copying-so-there-is-still-memory-available-for

Mais la théorie est complètement différente, et la solution que j'ai utilisée n'est pas liée à la vôtre, mais fonctionne parfaitement.

J'utilisais rsync, donc tout ce que j'avais à faire était d'utiliser l'option --drop-cache. (ce qui rend la copie un peu plus lente comme effet secondaire)


0

La seule astuce que j'ai trouvée qui fonctionne vraiment: Gnome, la copie de fichiers nautilus sur USB s'arrête à 100% ou près

Si vous souhaitez essayer quelques astuces pour les utilisateurs expérimentés, vous pouvez réduire la taille du tampon utilisé par Linux en définissant / proc / sys / vm / dirty_bytes à quelque chose comme 15728640 (15 Mo). Cela signifie que l'application ne peut pas obtenir plus de 15 Mo avant sa progression réelle.

Un effet secondaire est que votre ordinateur peut avoir un débit d'écriture de données inférieur avec ce paramètre, mais dans l'ensemble, je trouve utile de voir qu'un programme s'exécute longtemps alors qu'il écrit beaucoup de données contre la confusion d'avoir un Le programme semble avoir terminé son travail, mais le système est à la traîne car le noyau fait le travail réel. La définition de dirty_bytes sur une valeur raisonnablement petite peut également aider à empêcher votre système de ne plus répondre lorsque vous manquez de mémoire et exécutez un programme qui écrit soudainement beaucoup de données.

Mais ne le mettez pas trop petit! J'utilise 15 Mo comme estimation approximative du fait que le noyau peut vider le tampon sur un disque dur normal en 1/4 de seconde ou moins. Cela empêche mon système de se sentir "lent".

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.