Sprawdź dalej zapisy na dysku, aby dowiedzieć się, który proces zapisuje na moim dysku SSD


11

Próbuję zminimalizować zapisy na dysku do mojego nowego dysku systemowego SSD. Utknąłem z wyjściem iostatu:

~ > iostat -d 10 /dev/sdb
Linux 2.6.32-44-generic (Pluto)     13.11.2012  _i686_  (2 CPU)

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               8,60       212,67       119,45   21010156   11800488

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               3,00         0,00        40,00          0        400

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               1,70         0,00        18,40          0        184

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               1,20         0,00        28,80          0        288

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               2,20         0,00        32,80          0        328

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               1,20         0,00        23,20          0        232

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               3,40        19,20        42,40        192        424

Jak widzę, są zapisy do sdb. Jak mogę rozwiązać, który proces zapisuje?

Wiem o iotop , ale nie pokazuje, który system plików jest dostępny.

Odpowiedzi:


7

Poniżej zastosowano mechanizm zrzutu bloku pamięci wirtualnej jądra. Najpierw pobierz skrypt perla:

wget https://raw.githubusercontent.com/true/aspersa-mirror/master/iodump

Następnie włącz zrzut bloku:

echo 1 | sudo tee /proc/sys/vm/block_dump

I uruchom następujące:

while true; do sleep 1; sudo dmesg -c; done  | perl iodump

.. i naciśnij, Controlcaby zakończyć, zobaczysz coś takiego:

^C# Caught SIGINT.
TASK                   PID      TOTAL       READ      WRITE      DIRTY DEVICES
jbd2/sda3-8            620         40          0         40          0 sda3
jbd2/sda1-8            323         21          0         21          0 sda1
#1                    4746         11          0         11          0 sda3
flush-8:0             2759          7          0          7          0 sda1, sda3
command-not-fou       9703          4          4          0          0 sda1
mpegaudioparse8       8167          2          2          0          0 sda3
bash                  9704          1          1          0          0 sda1
bash                  9489          1          0          1          0 sda3
mount.ecryptfs_       9698          1          1          0          0 sda1

I wyłącz zrzut bloków, gdy skończysz:

echo 0 | sudo tee /proc/sys/vm/block_dump

Dzięki http://www.xaprb.com/blog/2009/08/23/how-to-find-per-process-io-statistics-on-linux/ za te pomocne informacje.


10

Możesz przynajmniej zacząć od iotop. Nie powie ci, który system plików jest zapisywany, ale da ci kilka procesów do zbadania.

sudo apt-get install iotop
sudo iotop

Pokazuje natychmiastowe odczyty i zapisy na dysku oraz nazwę polecenia odczytu lub zapisu.

Jeśli próbujesz złapać proces, który pisze rzadko, możesz użyć --accumulateopcji lub zapisać dane wyjściowe w pliku:

sudo -i
iotop --batch > iotop_log_file

Oczywiście zapis pliku dziennika pojawi się w wynikach, ale powinieneś być również w stanie grep dla innych procesów zapisujących na dysk.

W tym momencie powinieneś być w stanie znaleźć podejrzane procesy kandydujące. Lewa kolumna w iotop pokazuje pid. Następnie dowiedz się, do którego deskryptora pliku pisze proces:

sudo -i
strace -p <pid> 2>&1 | grep write

Powinieneś zobaczyć takie dane wyjściowe, gdy proces pisze:

write(1, "\n", 1)                       = 1
write(4, "test\n", 5)                   = 5
write(1, ">>> ", 4)                     = 4

Pierwszym argumentem do zapisania jest deskryptor pliku. Prawdopodobnie szukamy wartości większych niż 2, ponieważ 0, 1 i 2 to po prostu stdin, stdout i stderr. Deskryptor pliku 4 wygląda interesująco.

Teraz możesz dowiedzieć się, na jaki plik wskazuje deskryptor pliku:

lsof -p <pid>

Który powinien dać wynik jak:

...
python  23908  rob  mem    REG    8,1    26258 8392656 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
python  23908  rob    0u   CHR  136,5      0t0       8 /dev/pts/5
python  23908  rob    1u   CHR  136,5      0t0       8 /dev/pts/5
python  23908  rob    2u   CHR  136,5      0t0       8 /dev/pts/5
python  23908  rob    3w   REG   0,25      909 9049082 /home/rob/testfile
python  23908  rob    4w   REG   0,25       20 9049087 /home/rob/another_test_file

Spójrz na czwartą kolumnę. 4woznacza, że ​​deskryptor pliku 4 jest otwarty do zapisu, a plik jest another_test_file.

Możliwe jest, że proces otworzy, zapisze, a następnie zamknie plik, w którym to przypadku lsof nie pokazałby go. Możesz to złapać, gdy:

strace -p <pid> 2>&1 | grep open

Nie wiedziałem o --accumulte To naprawdę fajna funkcja! Dziękuję ci bardzo za to!!! Przekierowanie wyjścia iotop --batch kończy się niepowodzeniem w przypadku UnicodeEncodeError: kodek „ascii” nie może zakodować znaków w pozycjach 92-99: porządek poza zakresem (128) w pliku „/usr/lib/pymodules/python2.6/iotop/ui. py ”, wiersz 405, w refresh_display
zuba

Cieszę się, że moja odpowiedź była co najmniej przydatna. Przekierowanie działa dla mnie; nie jestem pewien, czy potrafię to wyjaśnić.
Rob Fisher

Ok, bawiłem się trochę i odkryłem, że mogę użyć lsof i strace, aby przynajmniej wykonać wystarczająco dużo pracy detektywistycznej, aby złapać procesy zapisujące się na dysku SSD. Mam nadzieję, że to ostatecznie odpowiada na zadane pytanie, choć wygląda na to, że odpowiedź Colina Iana Kinga jest łatwiejsza!
Rob Fisher

1
Przepraszam za spóźnioną odpowiedź, nie miałem nic do powiedzenia, dopóki nie grałem strace. Dziękuję za to inne sprytne podejście, głosowałem. Z powodu niewielkiego doświadczenia w pisaniu skryptów powłoki bardzo trudno było mi napisać skrypt, aby go zaimplementować. Dlatego wybrałem inne rozwiązanie. Dziękujemy za podzielenie się swoją wiedzą!
zuba

Powinno być --accumulated, ale wymiana stosu wymaga 6 znaków do zaakceptowania edycji postu.
h__
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.