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 10cp
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
yfree - m
et ce, même en tenant compte du temps de construction0 votes
Je ne vois rien de pertinent là-dedans, mais je viens de l'ajouter (je ne sais pas ce que vous entendez par "build time". C'est un noyau "Debian vanilla". J'ai mis
uname -a
).0 votes
Ok, pouvez-vous faire les mêmes commanfs pendant la construction d'emacs ? pour moi, il semble que vous vous heurtiez à un problème de swapping.
0 votes
Non, le problème apparaît déjà pendant
cp
Il ne s'agit donc pas d'un échange. Et il n'y a pas d'échange (je garde exactement les mêmes213
MB utilisé dans l'échange) pendant toute la durée de la construction.