Измерять задержки ввода-вывода на диске для выполняемого процесса

Я пытаюсь измерить задержки ввода-вывода на диске для выполняемого процесса, чтобы сделать гистограмму.

Я мог бы сделать это с помощью DTrace в операционных системах, которые его предоставляют (например, как в этой бумаге Joyent ), но мое приложение работает в Linux. Моя первая мысль заключалась в том, чтобы попробовать perf , и я могу получить счетчики, но я не могу найти способ получить время дельт. Я могу получить временные дельта с помощью strace (например, strace -e read -T ), но я не уверен, могу ли я ограничить трассировку на диск IO (эта система также имеет загруженный сетевой интерфейс).

Есть ли способ сделать это в Linux?

  • Удаление пустого файла, почему так много вызовов sys?
  • Linux strace не соответствует дочерним процессам даже с -f (многопоточным родителем)
  • Выход Grepping strace становится тяжелым
  • Неустранимые процессы apache2
  • почему strace игнорирует мой псевдоним для rm?
  • SIGSEGV: 0x0000000000000000 in ?? ()
  • Очень медленное автозаполнение в Linux для Windows
  • ptrace: операция не допускается при присоединении к процессу зомби
  • 2 Solutions collect form web for “Измерять задержки ввода-вывода на диске для выполняемого процесса”

    Это на самом деле сложно. Но есть подсказки:

    • Узнайте о SystemTap, это аналог Linux DTrace. Я думаю, что они могут даже иметь пример скрипта для аналогичной задачи.

    • Изучите blktrace . Теоретически вы можете анализировать его вывод. Это будет больше задержки устройства (время обслуживания), чем программа времени ответа на read() .

    Да, strace может оказаться нецелесообразным, поскольку он будет отслеживать все (все системные вызовы, даже если вы используете -e фильтр) и значительно загрузите сервер и медленнее процесс. Perf – очень неясный инструмент, у вас могут быть моменты, когда вы думаете, что понимаете его вывод, но на самом деле этого не делали, и его набор функций сильно зависит от версии ядра. В основном и в настоящее время perf подходит для измерения времени процессора (циклов) и [пока] неподходящего для измерения времени ответа (что вам действительно нужно). Я слышал, что они хотят реализовать что-то, чтобы облегчить это, поэтому на самых последних ядрах разработки может быть что-то. (Посмотрите также в пер-скриптах ( perf script -l ), если вы будете исследовать дальше.)

    • Может быть, вы сможете получить что-то от ftrace . Прочтите эту статью http://lwn.net/Articles/370423/ (И это для вступления .) Как я вижу, вы можете ограничить ftracing pid и функцией, а затем проследить с чем-то вроде sys_read . Я попробовал это как пример для вас:

       # mount -t debugfs debugfs /sys/kernel/debug # if it's not already mounted # cd /sys/kernel/debug/tracing # echo $$ > set_ftrace_pid # pid of process to trace # echo sys_read sys_write > set_ftrace_filter # echo function_graph > current_tracer # head trace # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 0) 8.235 us | sys_write(); 0) 3.393 us | sys_write(); 0) ! 459859.3 us | sys_read(); 0) 6.289 us | sys_write(); 0) 8.773 us | sys_write(); 0) ! 1576469 us | sys_read(); 

    Если вас интересует только количество запросов «читать» или «писать» для блокировки устройств, это SOP Red Hat для определения этого .

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

    Отключите системный журнал в течение короткого периода времени (чтобы он не мешал захвату данных):

    # service syslog stop # echo 1> / proc / sys / vm / block_dump

    Подождите, пока возникнет проблема с высоким уровнем iowait, после того, как он прошёл повторный активировать syslog (или rsyslog при его использовании) и отключить дамп блока:

    # service syslog start # echo 0> / proc / sys / vm / block_dump

    Используя следующую команду, проанализируйте вывод dmesg для действий READ / WRITE / dirtied, выдаваемых определенными процессами:

    # dmesg | awk '/ (READ | WRITE | загрязнено) / {activity [$ 1] ++} END {для (x в активности) print x, activity [x]}' | sort -nr -k 2,2 | head -n 10

    kjournald (1425): 5984 kjournald (3681): 1269 pdflush (27301): 725 iostat (2913): 134 crond (26919): 61 crond (28985): 60 crond (7026): 54 sshd (28175): 50 sshd ( 15388): 50 nautilus (24498): 46

    В приведенном выше примере показан верхний 10 процессов, которые выдали READ, WRITE и загрязненные операции за время выполнения дампа блока. Используя эти данные, можно собрать высокоуровневый обзор количества операций операций, и это может помочь определить, способствует ли один процесс высокому уровню для iowait.

    Есть также несколько инструментов командной строки, таких как atop и iotop, которые дают вам статистику по каждому процессу iowait и могут запускаться как часть скрипта (что означает, что у них есть пакетные режимы, которые могут выполнять одну итерацию для определенных PID).


    EDIT: делая больше исследований, похоже, что вы можете получить iowait для каждого процесса из / proc / $ pid / stat (поиск «Задержки агрегатного ввода-вывода»)

    Interesting Posts

    Установка FreeRADIUS – библиотека talloc не найдена

    Как отправить всю информацию в файл / var / adm / message в удаленную систему?

    Запуск приложения как root во время загрузки на Ubuntu 14.04

    расширить размер файловой системы reiserfs

    Понимание опции (-ключ) find (1) (фигурные скобки и знак плюс)

    Какое программное обеспечение отвечает за проверку прав доступа к файлам для пользователей или нет?

    передавать много похожих файлов по ssh

    Как переместить файлы в подкаталоги по счету?

    Можно ли наложить какой-то мягкий предел на потребление памяти процессами?

    Создание GNU-части GNU / Linux

    найти файлы, не соответствующие списку шаблонов имен файлов

    Запись скринкаста на неактивное рабочее пространство

    Поиск списков файлов с конкретными разрешениями

    Отдельные мониторы с отдельным входом клавиатуры и мыши?

    Доступна ли какая-либо специальная информация (например, предыдущая команда) для PROMPT_COMMAND?

    Linux и Unix - лучшая ОС в мире.