Linux who use disk

Выявляем процессы с дисковой активностью в Linux

TL;DR: статья рассказывает об удобном, быстром и надежном способе определения Linux-программ, записывающих данные на диск, что помогает в выявлении большой или аномально частой нагрузки на дисковую подсистему, а также позволяет оценить накладные расходы файловой системы. Это особенно актуально для SSD в ПК, EMMC и Flash-памяти в одноплатных компьютерах.
В ходе написания статьи обнаружилось, что запись нескольких килобайт данных на файловую систему BTRFS приводит к записи 3 мегабайт реальных данных на диск.

Введение

После 7 месяцев использования нового SSD я решил проверить количество записанных данных, как их сообщает сам диск через SMART.
19.7 ТБ.
Всего за 7 месяцев я использовал 13% от гарантированного количества записанных данных, притом, что он настроен в соответствии с рекомендациями по выравниваю разделов и настройке ФС, swap у меня почти не используется, диски виртуальных машин размещены на HDD!
Это аномально большая цифра, такими темпами гарантийный TBW будет превышен раньше достижения 5-летнего срока гарантии диска. Да и не может мой компьютер писать по 93 гигабайта в сутки! Нужно проверить, сколько данных пишется на диск за 10 минут…

Total:
Writes Queued: 24,712, 2,237MiB
Writes Completed: 25,507, 2,237MiB
Write Merges: 58, 5,472KiB

Определение количества записанных данных на дисковое устройство

Мой SSD хранит количество записанных данных в параметре 241 Total_LBAs_Written, в логических блоках (LBA), а не в байтах. Размер логического блока в моём случае — 512 байт (его можно увидеть в выводе smartctl, в Sector Size). Чтобы получить байты, нужно умножить значение параметра на 512.

Программа skdump на моём SSD пытается интерпретировать значение Total_LBAs_Written как-то по-своему, из-за чего выводит 1296217.695 TB , что, очевидно, некорректно.

Чтобы узнать количество записываемой информации на уровне устройства, воспользуемся программой btrace из состава пакета blktrace . Она показывает как общую статистику за всё время работы программы, так и отдельные процессы и потоки (в т.ч. ядра), которые выполняли запись.

Запустите следующую команду, чтобы собрать информацию за 10 минут, где /dev/sdb — ваш диск:

btrace позволяет наглядно посмотреть реальное количество записанных данных, но понять, какие именно программы совершают запись, из её вывода сложно.

Определение программ, производящих запись на накопитель

Программа iotop покажет процессы, пишущие на диск, и размер записанных данных.
Наиболее удобный вывод обеспечивают следующие параметры:

В глаза бросается Firefox, записавший 283 мегабайта за несколько минут работы iotop.

Определение файлов, в которые производится запись

Информация о процессе, насилующим диск — хорошо, а пути, по которым производится запись — еще лучше.

Воспользуемся программой fatrace , которая отслеживает изменения файловой системы.

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

Из вывода видно, как хабр сохраняет мою статью в local storage браузера, пока я её пишу, а также расширение Group Speed Dial, которое, как удалось обнаружить именно с помощью fatrace, читает свои данные каждые 30 секунд. Именно читает, а не записывает: CW перед файлом говорит о том, что файл открывается на чтение и запись, с одновременным созданием файла, если он отсутствует (вызывается openat с флагом O_RDWR|O_CREAT), но не говорит, что в файл действительно писалась какая-либо информация.

На всякий случай, чтобы удостовериться в этом, воспользуемся strace, с фильтром на файловые системные вызовы:

Нет ни одного вызова write() , что говорит об отсутствии записи в файл.

Определение накладных расходов файловой системы

Большая разница в показаниях iotop и btrace натолкнула на мысль протестировать файловую систему путем ручной записи данных в файл и отслеживания показаний btrace.

Если полностью исключить запись на диск, загрузившись в emergency-режим systemd, и записать вручную пару байт данных в существующий файл, btrace на SSD с btrfs сообщает о записи 3 мегабайт реальных данных. Свежесозданная файловая система флешке размером в 8 ГБ записывает минимум 264 КиБ при записи одного байта.
Для сравнения, запись пары байт в файл на ext4 оканчивается записью 24 килобайтов данных на диск.

В 2017 году Jayashree Mohan, Rohan Kadekodi и Vijay Chidambaram провели исследование усиления записи разных файловых систем, их результаты для btrfs и ext4 при записи 4 КБ соотносятся с моими.

Источник

Кунг-фу стиля Linux: мониторинг дисковой подсистемы

Если, работая в Linux, нужно быстро взглянуть на сведения о работающих процессах — можно воспользоваться командой top , или — что немного лучше — командой htop . А как быть, если надо получить данные о состоянии дисковой подсистемы? Решить эту задачу помогут специализированные инструменты, некоторые из которых распространены далеко не так широко, как top .

Утилита iotop

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

Вот совет по работе с этой утилитой. Если взглянуть на нижнюю часть экрана — там можно найти некоторые команды, вызываемые нажатиями на клавиши клавиатуры. Например, клавиша O скрывает (или отображает) все неактивные процессы. Это позволяет немного улучшить внешний вид сведений, выводимых iotop .

Сведения об использовании дисковой подсистемы активными процессами

Того же эффекта можно добиться, запустив iotop с ключом -o . Обратите внимание на то, что другие клавиатурные команды позволяют, например, выводить сведения о потоках, а не о процессах, менять режим вывода данных, задавать классы и приоритеты ввода-вывода процессов ( ionice ).

Утилита iostat

Если вас больше интересуют данные, относящиеся к самим дискам, а не к процессам или потокам, можете попробовать команду iostat . Она тоже выводит некоторые данные о процессах, но они представлены в обобщённом виде.

Работа с iostat

Эта команда запускается, собирает данные и выводит их, не обновляя в режиме реального времени. Если нужно периодически её перезапускать — можно, при её запуске, указать промежуток времени между получениями новых отчётов, и, что необязательно, общее количество перезапусков. При этом, если нужно, можно воспользоваться ключом командной строки -t для получения сведений о времени.

Правда, это приводит к прокрутке выходных данных программы. Если вы занимаетесь мониторингом дисковой активности, то, возможно, вам лучше подойдёт такой вариант запуска iostat :

Если запустить утилиту с ключом -x — можно получить более подробные сведения о дисках. Флаг -z позволяет отключить вывод сведений об устройствах, на которых нет данных.

Утилита duf

Вы, вероятно, не найдёте в своей системе утилиту duf . Если это так — можете установить её с GitHub. Те же результаты, правда, можно получить, воспользовавшись df и ещё некоторыми командами, но преимущество duf заключается в том, что эта программа представляет данные в удобном для просмотра виде.

При запуске этой утилиты можно воспользоваться опциями командной строки, которые позволяют скрывать устройства, задавать ширину таблиц, выводимых на экране, по-разному сортировать выводимые данные. Ещё можно указать максимальную ширину таблиц, генерируемых программой. Подробности о работе с duf можно узнать, запустив утилиту с ключом —help .

Вывод сведений об открытых файлах с помощью lsof

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

При использовании lsof нужно помнить о том, что шаблоны тут, по умолчанию, не работают. Поэтому следующая команда выведет лишь сведения о директории /home/alw . А вот, например, сведения о процессах, которые открыли какие-нибудь файлы в этой директории, такая команда не выведет.

Для того чтобы это изменить, можно запустить lsof с ключом -d или -D . Ключ, представленный буквой в нижнем регистре, приводит к поиску директорий и файлов на верхнем уровне. Ключ -D выполняет рекурсивный поиск. Эта команда поддерживает и много других опций, которые можно применять, например, для поиска файлов, открытых пользователем с заданным ID, или для поиска по заданному имени команды.

Дополнительный инструмент: atop

Одной из замен команды top является atop . Хотя эта команда и не нацелена исключительно на мониторинг дисковых операций, она даёт сведения о том, как процессы пользуются дисками, и, кроме того, предоставляет некоторые сводные сведения. Обычно после запуска atop в верхней части формируемого ей вывода имеется строка DSK , в которой присутствуют сведения о диске. Эти данные, по мере приближения уровня использования диска к 100%, выделяются красным цветом. Данные, выводимые в нижней части, похожи на те, что даёт команда top .

Для сортировки процессов по уровню использования дисков можно воспользоваться клавишей D . Это — полезный инструмент.

Итоги

Для того чтобы получить сведения о дисках в Linux можно применить десятки различных инструментов. Собственно говоря, нечто подобное справедливо и для решения многих других задач. Если вам интересны подробности о том, что именно выводит htop (похожие данные формируют, кроме того, top и atop ) — взгляните на этот материал.

Как вы мониторите дисковую подсистему в Linux?

Источник

How do I find out what processes are accessing the hard disk in a GNU/Linux-based system?

I’m looking for the equivalent to top for disk access, so I can tell which process(es) are currently reading and/or writing to disk. I’m currently using Ubuntu, but I imagine there’s a standard tool that’s available as part of the GNU toolset.

4 Answers 4

You got three-fifths of the answer right yourself — the one you want is called iotop. Search for it in the extra repositories, it should be there.

htop » F2 » Columns » Active Columns » IO_RATE

Then sort by this column. Also you can add IO_READ_RATE and IO_WRITE_RATE columns and sort according to them.

iotop is the counterpart to top that watches I/O usage information. If you want detailed information on the files opened by a process, or the list of files opened in a directory, or watch over files in the whole system, use lsof . lsof is quite versatile and provides information about open tcp, udp, NFS connections too.

Atop is an ASCII full-screen performance monitor that is capable of reporting the activity of all processes (even if processes have finished during the interval), daily logging of system and process activity for long-term analysis, highlighting overloaded system resources by using colors, etc. At regular intervals, it shows system-level activity related to the CPU, memory, swap, disks and network layers, and for every active process it shows the CPU utilization, memory growth, disk utilization, priority, username, state, and exit code.

Источник

How to check disk I/O utilization per process?

I’m having a problem with a Linux system and I have found sysstat and sar to report huge peaks of disk I/O, average service time as well as average wait time.

How could I determine which process is causing these peaks the next time it happen?

Is it possible to do with sar ? Can I find this info from the already recorded sar files?

Output of sar -d , system stall happened around 12.58-13.01pm.

I also have this follow-up question to another thread I started yesterday:

5 Answers 5

If you are lucky enough to catch the next peak utilization period, you can study per-process I/O stats interactively, using iotop.

You can use pidstat to print cumulative io statistics per process every 20 seconds with this command:

Each row will have follwing columns:

• PID — process ID
• kB_rd/s — Number of kilobytes the task has caused to be read from disk per second.
• kB_wr/s — Number of kilobytes the task has caused, or shall cause to be written to disk per second.
• kB_ccwr/s — Number of kilobytes whose writing to disk has been cancelled by the task. This may occur when the task truncates some dirty pagecache. In this case, some IO which another task has been accounted for will not be happening.
• Command — The command name of the task.

Output looks like this:

. Also, if you want a snapshot (not continually updating), add 1 after the command in the answer ( man pidstat for more details), for example: pidstat -G suspect_proc -dl 20 1

Nothing beats ongoing monitoring, you simply cannot get time-sensitive data back after the event.

There are a couple of things you might be able to check to implicate or eliminate however — /proc is your friend.

Fields 10, 11 are accumulated written sectors, and accumulated time (ms) writing. This will show your hot file-system partitions.

Those fields are PID, command and cumulative IO-wait ticks. This will show your hot processes, though only if they are still running. (You probably want to ignore your filesystem journalling threads.)

The usefulness of the above depends on uptime, the nature of your long running processes, and how your file systems are used.

Caveats: does not apply to pre-2.6 kernels, check your documentation if unsure.

(Now go and do your future-self a favour, install Munin/Nagios/Cacti/whatever 😉

Источник

Linux: Which process is causing «device busy» when doing umount? [closed]

Want to improve this question? Update the question so it’s on-topic for Stack Overflow.

Closed 3 years ago .

Linux: Which process is causing «device busy» when doing umount?

12 Answers 12

Look at the lsof command (list open files) — it can tell you which processes are holding what open. Sometimes it’s tricky but often something as simple as sudo lsof | grep (your device name here) could do it for you.

Just in case. sometimes happens that you are calling umount from the terminal, and your current directory belongs to the mounted filesystem.

You should use the fuser command.

Eg. fuser /dev/cdrom will return the pid(s) of the process using /dev/cdrom .

If you are trying to unmount, you can kill theses process using the -k switch (see man fuser ).

Check for open loop devices mapped to a file on the filesystem with «losetup -a». They wont show up with either lsof or fuser.

Also check /etc/exports . If you are exporting paths within the mountpoint via NFS, it will give this error when trying to unmount and nothing will show up in fuser or lsof .

(as lists the processes using files on the mount mounted at /mountpoint. Particularly useful for finding which process(es) are using a mounted USB stick or CD/DVD.

lsof and fuser are indeed two ways to find the process that keeps a certain file open. If you just want umount to succeed, you should investigate its -f and -l options.

That’s exactly why the «fuser -m /mount/point» exists.

BTW, I don’t think «fuser» or «lsof» will indicate when a resource is held by kernel module, although I don’t usually have that issue..

lsof and fuser didn’t give me anything either.

After a process of renaming all possible directories to .old and rebooting the system every time after I made changes I found one particular directory (relating to postfix) that was responsible.

It turned out that I had once made a symlink from /var/spool/postfix to /disk2/pers/mail/postfix/varspool in order to minimise disk writes on an SDCARD-based root filesystem (Sheeva Plug).

With this symlink, even after stopping the postfix and dovecot services (both ps aux as well as netstat -tuanp didn’t show anything related) I was not able to unmount /disk2/pers.

When I removed the symlink and updated the postfix and dovecot config files to point directly to the new dirs on /disk2/pers/ I was able to successfully stop the services and unmount the directory.

Next time I will look more closely at the output of:

The above command will recursively list all symbolic links in a directory tree (here starting at /var) and filter out those names that point to a specific target mount point (here disk2).

Источник