1 votes

Ecritures limitées à 500KB/s ?

Mon ordinateur portable, qui fonctionne sous Debian testing, a récemment été terriblement lent lors des opérations impliquant l'écriture sur le disque.

Je n'ai aucune idée de l'origine du problème et j'aimerais que l'on m'aide à le localiser et à le résoudre.

Voici les symptômes que j'ai remarqués :

  • iotop affichera généralement dans "DISK WRITE" une bande passante très proche de 500KB/s pour tout processus en cours d'écriture sur le disque (par ex. cp , dpkg , ...).
  • Cela se produit quelle que soit la charge de l'unité centrale.
  • Running 1 cp permet d'obtenir une bande passante d'écriture totale d'environ 500KB/s. Exécution de 10 cp Il en résulte une bande passante d'écriture totale d'environ 5 Mo/s.
  • Il s'agit d'un système de fichiers ext4 sur un volume LVM sur un disque SSD. Le point précédent suggère fortement que la limite ne vient pas du matériel, mais juste au cas où, j'ai cloné le système sur un autre SSD et j'ai obtenu le même résultat.
  • Ce problème n'affecte pas la machine après un nouveau démarrage mais semble n'apparaître qu'après un certain temps (c'est-à-dire après quelques suspensions et réveils, mais je n'ai aucune idée si c'est lié).
  • Le ralentissement est particulièrement sensible lors de la construction d'Emacs, où l'une des phases de la construction génère un fichier dit "pdump" d'environ 7 Mo via de nombreux petits fichiers de données. write et où iotop m'indique que le processus finit par effectuer un total de plus de 400 Mo d'écritures sur le disque (à 500 Ko/s, d'où un temps de plus de 10 minutes pour écrire ce misérable fichier de 7 Mo). Cela suggère que le fichier est "synchronisé" à une granularité terriblement fine, bien que je ne voie rien dans le code source qui justifie ce comportement.
  • J'ai essayé de fsck -f après l'un des redémarrages et il n'a pas signalé de problème.
  • dmesg ne contient aucun message inhabituel provenant des couches ext4 ou lvm ou de la couche de périphérique de bloc.
  • Le problème affecte les trois systèmes de fichiers que j'utilise sur le disque SSD (tous trois utilisant ext4 dans le même groupe de volumes LVM). Il n'affecte pas le /tmp monté en tmpfs.
  • Cette machine fonctionne avec les derniers tests de Debian et montre ces signes depuis quelques mois maintenant, avec différents noyaux (maintenant avec 5.2.0-2-686-pae (je ne suis pas sûr de la première version du noyau avec laquelle j'ai rencontré ce problème).

Comme demandé, voici quelques informations supplémentaires.

% df -h
Sys. de fichiers          Taille Utilisé Dispo Uti% Monté sur
udev                        3.9G       0  3.9G   0% /dev
tmpfs                       796M     26M  770M   4% /run
/dev/mapper/Alfajor-root     19G     16G  2.3G  88% /
tmpfs                       3.9G     30M  3.9G   1% /dev/shm
tmpfs                       5.0M    8.0K  5.0M   1% /run/lock
tmpfs                       3.9G       0  3.9G   0% /sys/fs/cgroup
tmpfs                       512M    8.0K  512M   1% /tmp
/dev/mapper/Alfajor-cache   7.8G    6.7G  1.1G  87% /var/cache
/dev/mapper/Alfajor-home     41G     37G  1.8G  96% /home
tmpfs                       796M     12K  796M   1% /run/user/122
% free -m
              total        used        free      shared  buff/cache   available
Mem:           7952        1188        2724         212        4039        5858
Swap:          4095         213        3882
% uname -a
Linux alfajor 5.3.0-3-686-pae #1 SMP Debian 5.3.15-1 (2019-12-07) i686 GNU/Linux
%

0 votes

Vérifie l'absence d'erreurs dans le système de fichiers et indique l'état actuel de votre système et de la construction.

0 votes

J'ai mis à jour ma question avec cette information,

0 votes

Il me manque toujours les sorties de df -h y free - m et ce, même en tenant compte du temps de construction

0voto

Stefan Points 133

Je ne suis toujours pas complètement sûr de l'origine du problème, mais j'ai changé mon noyau de i686-pae a amd64 et cela semble avoir résolu le problème (le reste de mon système fonctionne toujours avec le portage i386 de Debian). Je pense qu'il s'agit d'un problème dans la gestion de la mémoire PAE par le noyau (probablement parce que certains tampons doivent se trouver dans les 2 ou 4 premiers Go de RAM pour être accessibles).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X