Изучите возможность записи на диск, чтобы выяснить, какой процесс записывает данные на мой SSD


11

Я пытаюсь свести к минимуму записи на диск на мой новый системный диск SSD. Я застрял с выводом iostat:

~ > 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

Как я вижу, есть записи в SDB. Как я могу решить, какой процесс пишет?

Я знаю о iotop , но он не показывает, к какой файловой системе обращаются.

Ответы:


7

Далее используется механизм дампа блока виртуальной памяти ядра. Сначала получите скрипт perl:

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

Затем включите дамп блока:

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

И запустите следующее:

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

..и нажмите, Controlcчтобы закончить, вы увидите что-то вроде следующего:

^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

И выключите дамп блока, когда вы закончите:

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

Спасибо http://www.xaprb.com/blog/2009/08/23/how-to-find-per-process-io-statistics-on-linux/ за эту полезную информацию.


10

Вы могли бы по крайней мере начать с iotop. Он не скажет вам, какая файловая система пишется, но даст вам некоторые процессы для исследования.

sudo apt-get install iotop
sudo iotop

Он показывает мгновенное чтение и запись на диск и имя команды чтения или записи.

Если вы пытаетесь перехватить процесс, который пишет редко, вы можете использовать эту --accumulateопцию или записать вывод в файл:

sudo -i
iotop --batch > iotop_log_file

Очевидно, что запись файла журнала будет отображаться в результатах, но вы также должны иметь возможность искать другие процессы, записывающие на диск.

К этому моменту вы сможете найти несколько возможных подозрительных процессов. Левый столбец в iotop показывает pid. Затем выясните, в какой файловый дескриптор записывает процесс:

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

Вы должны увидеть вывод, как этот, когда процесс пишет:

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

Первым аргументом для записи является дескриптор файла. Вероятно, мы ищем значения больше 2, потому что 0, 1 и 2 - это просто stdin, stdout и stderr. Файловый дескриптор 4 выглядит интересно.

Теперь вы можете узнать, на какой файл указывает дескриптор файла:

lsof -p <pid>

Который должен давать результат как:

...
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

Посмотрите на 4-й столбец. 4wозначает, что файловый дескриптор 4 открыт для записи, а файл - another_test_file.

Процесс может открыть, записать, а затем закрыть файл, и в этом случае lsof не покажет его. Вы можете заметить, что это происходит с:

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

Я не знал о --accumulte Это действительно классная функция! Большое спасибо за это !!! iotop - сбой перенаправления выходных данных с UnicodeEncodeError: кодек «ascii» не может кодировать символы в позиции 92-99: порядковый номер не в диапазоне (128) в файле «/usr/lib/pymodules/python2.6/iotop/ui. py ", строка 405, в refresh_display
zuba

Я рад, что мой ответ был хоть как-то полезен. Перенаправление работает для меня; не уверен, что могу это объяснить.
Роб Фишер

Хорошо, я немного поиграл и обнаружил, что могу использовать lsof и strace, чтобы хотя бы выполнить достаточно детективной работы, чтобы перехватывать процессы, записывающие на SSD. Надеюсь, это, наконец, ответит на вопрос в том виде, в котором оно было задано, хотя похоже, что ответ Колина Яна Кинга легче!
Роб Фишер

1
Извините за поздний ответ, мне нечего было сказать, пока я не поиграл со стразами. Спасибо за это еще один умный подход, я проголосовал. Мне было довольно сложно написать сценарий для его реализации из-за небольшого опыта в написании сценариев оболочки. Вот почему я выбрал другое решение. Спасибо, что поделились своими знаниями!
Зуба

Должно быть --accumulated, но стек обмена требует 6 символов, чтобы принять редактирование сообщения.
19
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.