Come trovare quale processo scrive regolarmente su disco?

42

Come posso trovare quale processo scrive costantemente su disco?

Mi piace che la mia workstation sia vicina al silenzio e ho appena costruito un nuovo sistema (P8B75-M + Core i5 3450s - la 's' perché ha un TDP massimo inferiore) con ventole silenziose ecc. E installato Debian Wheezy a 64 bit su di esso.

E qualcosa mi sta innervosendo: riesco a sentire una specie di modello come se il disco rigido stesse scrivendo o cercando qualcosa ( tick ... tick ... tick ... trrrrrr risciacquo e ripetere ogni secondo circa).

In passato ho avuto un problema simile in passato (molti, molti anni fa) e si è scoperto che si trattava di un registro CUPS o qualcosa del genere e ho semplicemente reindirizzato quel registro (non importante) su un disco (reale) RAM.

Ma qui non ne sono sicuro.

Ho provato quanto segue:

ls -lR /var/log > /tmp/a.tmp && sleep 5 && ls -lR /var/log > /tmp/b.tmp && diff /tmp/?.tmp

ma nulla sta cambiando lì.

Ora la cosa strana è che sento anche lo schema quando viene visualizzato il prompt che mi chiede di inserire la mia passphrase di decrittazione LVM.

Potrebbe essere qualcosa nel kernel / sistema che ho appena installato o ho un disco rigido difettoso?

hdparm -tT /dev/sda segnalare una velocità HD corretta (130 GB / s non memorizzata nella cache, sata 6 GB) e ho già installato e compilato da grandi fonti (Emacs) senza problemi, quindi non credo che il sistema sia difettoso.

(HD è un Barracude Seagate da 500 GB)

— Cedric Martin
fonte

Sei sicuro che sia un disco rigido a fare quel rumore, e non qualcos'altro? (Controlla le ventole, inclusa la ventola dell'alimentatore. Una volta aveva dei rumori di clic molto strani quando un cavo molto sottile era troppo vicino a una ventola e qualche volta toccava leggermente le pale e rimbalzava per alcuni "clic" ...)

— Mat

@Mat: porterò il disco rigido fuori dal case (i connettori dovrebbero essere abbastanza lunghi) per essere sicuro e riporterò indietro; )

— Cedric Martin il

2

Assicurati che i filesystem del tuo disco siano montati relatime o noatime. Le letture dei file possono causare scritture negli inode per registrare il tempo di accesso.

— Camh,

43

Hai provato ad esaminare quali programmi iotopsta mostrando? Ti dirà esattamente quale tipo di processo sta scrivendo sul disco.

esempio di output:

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]

— mnmnc
fonte

1

grazie per quel suggerimento. Non sapevo di iotop . Su Debian ho fatto un iotop di ricerca nella cache di apt per scoprire che dovevo apt-get iotop . Comando davvero fantastico!

— Cedric Martin,

3

Uso iotop -o -b -d 10che ogni 10 secondi stampa un elenco di processi che leggono / scrivono su disco e la quantità di larghezza di banda di I / O utilizzata.

— ndemou,

15

È possibile abilitare il debug IO tramite echo 1 > /proc/sys/vm/block_dumpe quindi guardare i messaggi di debug in / var / log / syslog . Ciò ha il vantaggio di ottenere un certo tipo di file di registro con le attività passate mentre iotopmostra solo l'attività corrente.

— SCAI
fonte

4

È assolutamente folle lasciare abilitato lo sysloging quando block_dump è attivo. La registrazione provoca l'attività del disco, che causa la registrazione, che causa l'attività del disco ecc. Meglio interrompere syslog prima di abilitare questo (e usare dmesg per leggere i messaggi)

— dan3

Hai assolutamente ragione, anche se l'effetto non è così drammatico come lo descrivi. Se vuoi solo dare una breve occhiata all'attività del disco, non è necessario arrestare il demone syslog.

— scai,

L'ho provato circa 2 anni fa e ha fermato la mia macchina. Uno di questi giorni in cui non avrò nulla di importante, ci riproverò :)

— dan3,

L'ho provato, non è successo davvero niente. Soprattutto a causa del buffering del file system. Una scrittura su syslog non attiva immediatamente una scrittura su disco.

— scai,

1

Suppongo che sia in atto un limite di velocità generale per i messaggi di registro, che gestisce anche questo caso (?)

— Volker Siegel,

5

Supponendo che i rumori del disco siano dovuti a un processo che causa una scrittura e non a un problema di spindown del disco , è possibile utilizzare il sottosistema di controllo (installare il auditdpacchetto ). Dai un'occhiata alle syncchiamate e ai suoi amici:

auditctl -S sync -S fsync -S fdatasync -a exit,always

Guarda i log in /var/log/audit/audit.log. Fare attenzione a non farlo se i log di controllo stessi vengono scaricati! Verifica /etc/auditd.confche l' flushopzione sia impostata su none.

Se i file vengono scaricati spesso, un probabile colpevole sono i registri di sistema. Ad esempio, se si registrano tentativi di connessione in entrata non riusciti e qualcuno sta sondando la macchina, ciò genererà molte voci; ciò può far sì che un disco emetta rumori di tipo mitragliatrice. Con il demone di registro di base sysklogd, controlla /etc/syslog.conf: se un nome di file di registro non è preceduto da -, allora quel registro viene scaricato sul disco dopo ogni scrittura.

— Gilles 'SO- smetti di essere malvagio'
fonte

@StephenKitt Huh. No. Il richiedente ha menzionato Debian, quindi l'ho cambiato in un collegamento al pacchetto Debian.

— Gilles 'SO-smetti di essere malvagio' il

3

Potrebbe essere che le tue unità si spengano automaticamente, molte unità di livello consumer lo fanno in questi giorni. Sfortunatamente anche su un sistema leggermente carico, ciò comporta che le unità ruotano costantemente verso il basso e poi si riaccendono, specialmente se si esegue hddtemp o simili per monitorare la temperatura dell'unità (la maggior parte delle unità stupidamente non consente di interrogare il valore di temperatura SMART senza girare il disco - cretinoso!).

Questo non è solo fastidioso, può logorare le unità più velocemente poiché molte unità hanno solo un numero limitato di cicli di parcheggio. ad esempio, consultare https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/952556 per una descrizione del problema.

Disattivo idle-spindown su tutte le mie unità con il seguente bit di codice shell. potresti metterlo in uno script /etc/rc.boot o in /etc/rc.local o simile.

per disco in / dev / sd? ; fare
  / sbin / hdparm -q -S 0 "$ disk"
fatto

— cas
fonte

2

che non è possibile interrogare letture SMART senza far girare l'unità mi lascia senza parole: - / Ora ovviamente il problema della "riduzione" può diventare piuttosto complicato. Per quanto riguarda la disabilitazione della rotazione verso il basso: ciò di per sé non causerebbe l'usura più rapida dell'HD? Voglio dire: non è mai "riposare" finché il sistema è acceso allora?

— Cedric Martin,

IIRC è possibile interrogare alcuni valori SMART senza causare la rotazione dell'unità, ma la temperatura non è una di queste su nessuna delle unità che ho testato (inclusi i modelli di WD, Seagate, Samsung, Hitachi). Il che è, ovviamente, pazzo perché la preoccupazione per la temperatura è uno dei motivi per far girare il motore al minimo. re: wear: AIUI 1. la velocità costante consuma meno della velocità variabile. 2. le unità devono parcheggiare le testine in un'area sicura e un'unità è classificata per farlo solo così tante volte (IIRC fino a qualche centinaio di migliaia - facilmente superabile se l'unità è al minimo e gira su ogni pochi secondi)

— cas

È un lungo dibattito sul fatto che sia meglio lasciare le unità in funzione o ridurle. Personalmente credo che sia meglio lasciarli in esecuzione: spengo il computer di notte e quando esco, ma a parte questo non spengo mai le mie unità. Alcune persone preferiscono abbassarle, diciamo, di notte se stanno lasciando il computer acceso o se il computer è inattivo per un lungo periodo di tempo, e in questi casi il vantaggio di farle girare per alcune ore rispetto a lasciarle in funzione è discutibile . Ciò che non è mai buono, tuttavia, è quando il disco rigido si gira e si riaccende ripetutamente in un breve periodo di tempo.

— Micheal Johnson,

Nota anche che girare l'unità dopo che è rimasto inattivo per alcune ore è un po 'sciocco, perché se è rimasto inattivo per alcune ore, è probabile che venga riutilizzato entro un'ora. In tal caso, sarebbe meglio far girare l'unità rapidamente se è inattiva (come, entro 10 minuti), ma è anche possibile che l'unità sia inattiva per alcuni minuti quando qualcuno sta usando il computer e probabilmente avrà bisogno l'unità di nuovo presto.

— Micheal Johnson,

Pensavo che questo avrebbe risolto il mio problema quando ho sentito che il suono del clacking periodico (3-4 volte al secondo) era come se stesse scrivendo anche quando non è montato! Ma sento ancora il rumore dopo aver eseguito questo comando. È preoccupante, è l'unità che utilizzo per eseguire il backup del mio SSD interno ...

— Michael

1

Ho appena scoperto che smart stava causando la rotazione continua di un disco USB esterno sul mio Raspberry Pi. Sebbene SMART sia generalmente una buona cosa, ho deciso di disabilitarlo di nuovo e da allora sembra che l'attività del disco indesiderata si sia fermata

— JRO
fonte

Puoi configurare il demone intelligente in modo che non esegua la scansione dei dischi USB, la maggior parte delle buone distribuzioni di Linux lo fanno di default.

— lzap,

1

Puoi scommetterci un po 'su questo. Dovrebbe restringerlo per la maggior parte.

find / -mount -newer /proc -print

Fornisci i file modificati dall'avvio sul dispositivo fisico del sistema / files. Conoscere i file probabilmente aiuterà a identificare lo scrittore.

— user190618
fonte

1

Nel caso in cui sia necessario restringerlo a un disco esatto, utilizzare quanto segue:

eseguire lsblke cercare il numero del dispositivo. Nel caso seguente lo è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

eseguire lsof | grep '9,126'con il :sostituire con ,rispetto al numero del disco sopra. Nel mio caso questo si presenta come:

bash      389162            root  cwd       DIR              9,126      4096  449183796 /mnt/InternalPhase/0000000001/CHANNEL01/LIVE/PHASE/DATA/2018/10/04

con il PID di 389162uccidere questo processo usando:

kill -9 389162

— Jacques MALAPRADE
fonte

-1

Il problema è che il sistema deve scaricare i dati dai buffer del disco sul disco ogni 5 secondi circa per impostazione predefinita. Pertanto, se il disco gira verso il basso, ci saranno poche opzioni oltre a tornare indietro quando è necessario un flush. Quindi il problema non è davvero evitabile se non disabilitando del tutto gli spin-down o le funzionalità di gestione dell'alimentazione del disco hdparm -B 255 /dev/hdax. Questa è probabilmente l'opzione migliore dal momento che il riavvio così spesso può sicuramente essere più dannoso del semplice restare sempre.

— paul reynolds
fonte

1

Svuota i dati solo se ci sono dati da svuotare. Se il disco non è realmente in uso, non ci saranno dati bufferizzati da scaricare.

— Micheal Johnson,