Comment trouver quel processus écrit régulièrement sur le disque?
Comment savoir quel processus écrit constamment sur le disque?
J'aime que mon poste de travail soit presque silencieux et je viens de construire un nouveau système (P8B75-M + Core i5 3450s - le 's' car il a un TDP max inférieur) avec des ventilateurs silencieux, etc. et installé Debian Wheezy 64 bits dessus.
Et quelque chose me tracasse: j'entends une sorte de schéma comme si le disque dur écrivait ou cherchait quelque chose (cochez ... cochez ... cochez ... trrrrrr rincez et répétez chaque seconde environ).
Dans le passé, j'ai eu un problème similaire dans le passé (il y a de nombreuses années) et il s'est avéré que c'était un journal CUPS ou quelque chose et j'ai simplement redirigé celui-là (pas important) vers un (vrai) RAM disque.
Mais ici, je ne suis pas sûr.
J'ai essayé ce qui suit:
ls -lR /var/log > /tmp/a.tmp && sleep 5 && ls -lR /var/log > /tmp/b.tmp && diff /tmp/?.tmp
mais rien n'y change.
Maintenant, la chose étrange est que j'entends également le modèle lorsque l'invite me demandant d'entrer ma phrase secrète de déchiffrement LVM s'affiche.
Serait-ce quelque chose dans le noyau/système que je viens d'installer ou ai-je un disque dur défectueux?
hdparm -tT /dev/sda signaler une vitesse HD correcte (130 Go/s non mis en cache, sata 6 Go) et j'ai déjà installé et compilé à partir de grandes sources (Emacs) sans problème, donc je ne pense pas que le système soit mauvais.
(HD est un Seagate Barracude 500 Go)
Avez-vous essayé d'examiner quels programmes comme iotop sont affichés? Il vous dira exactement quel type de processus écrit actuellement sur le disque.
exemple de sortie:
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % init
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
6 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/0]
7 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/0]
8 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/1]
1033 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [flush-8:0]
10 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/1]
Vous pouvez activer IO débogage via echo 1 > /proc/sys/vm/block_dump puis regardez les messages de débogage dans / var/log/syslog. Cela a l'avantage d'obtenir un certain type de fichier journal avec les activités passées alors que iotop n'affiche que l'activité actuelle.
En supposant que les bruits du disque sont dus à un processus provoquant une écriture et non à n problème de ralentissement du disque , vous pouvez utiliser le sous-système d'audit (installez le auditd package ). Surveillez les appels sync et ses amis:
auditctl -S sync -S fsync -S fdatasync -a exit,always
Regardez les journaux dans /var/log/audit/audit.log. Faites attention à ne pas le faire si les journaux d'audit eux-mêmes sont vidés! Enregistrement /etc/auditd.conf que l'option flush est définie sur none.
Si les fichiers sont souvent vidés, les journaux système sont probablement à l'origine de ce problème. Par exemple, si vous enregistrez des tentatives de connexion entrantes qui ont échoué et que quelqu'un sonde votre machine, cela générera de nombreuses entrées; cela peut provoquer l'émission de bruits de type mitrailleuse sur un disque. Avec le démon de journal de base sysklogd, vérifiez /etc/syslog.conf: si un nom de fichier journal n'est pas précédé de -, puis ce journal est vidé sur le disque après chaque écriture.
Il se peut que vos disques tombent automatiquement en panne, de nombreux disques grand public le font de nos jours. Malheureusement, même sur un système légèrement chargé, cela entraîne une baisse constante des disques, puis une nouvelle rotation, en particulier si vous exécutez hddtemp ou similaire pour surveiller la température du lecteur (la plupart des lecteurs ne vous permettent pas stupidement d'interroger le SMART valeur de température sans tourner le disque - crétineux!).
Ce n'est pas seulement gênant, cela peut épuiser les disques plus rapidement car de nombreux disques n'ont qu'un nombre limité de cycles de stationnement. par exemple. voir https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/952556 pour une description du problème.
Je désactive le ralenti-spindown sur tous mes disques avec le bit de code Shell suivant. vous pouvez le mettre dans un script /etc/rc.boot, ou dans /etc/rc.local ou similaire.
pour le disque dans/dev/sd? ; faire /sbin/hdparm -q -S 0 "$ disk" fait
Vous pouvez vous en douter un peu. Devrait le réduire pour la plupart.
find / -mount -newer /proc -print
Donnez les fichiers modifiés depuis le démarrage sur le périphérique physique du système/files. Connaître les fichiers aidera probablement à identifier l'auteur.
Je viens de découvrir que s.m.a.r.t faisait tourner un disque USB externe encore et encore sur mon Raspberry Pi. Bien que SMART est généralement une bonne chose, j'ai décidé de le désactiver à nouveau et depuis lors, il semble que l'activité indésirable du disque s'est arrêtée
Dans le cas où vous devez le réduire à un disque exact, utilisez ce qui suit:
exécutez lsblk et recherchez le numéro de périphérique. Dans le cas ci-dessous, c'est 9:126
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 7.3T 0 disk
└─md126 9:126 0 13.8T 0 raid0 /mnt/InternalPhase
sdb 8:16 0 7.3T 0 disk
└─md126 9:126 0 13.8T 0 raid0 /mnt/InternalPhase
sdc 8:32 0 7.3T 0 disk
└─sdc1 8:33 0 7.3T 0 part /mnt/InternalFBE
courir lsof | grep '9,126' avec le : remplacer par , par rapport au numéro de disque ci-dessus. Dans mon cas, cela se présente comme:
bash 389162 root cwd DIR 9,126 4096 449183796 /mnt/InternalPhase/0000000001/CHANNEL01/LIVE/PHASE/DATA/2018/10/04
avec le PID de 389162 tuer ce processus en utilisant:
kill -9 389162