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

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

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

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

  • MC и MCedit занять много времени
  • Почему нет / bin / login в выводе ps при входе в систему
  • Выход Strace не отображает системный вызов
  • Как «раскодировать» сокет домена unix?
  • Как определить, какие инструкции выполняет процесс?
  • Какой системный вызов используется для загрузки библиотек в Linux?
  • Как (если возможно) я могу закончить конкретный блокиратор, зависающий программой?
  • Можно ли привязать встроенные команды к Bash?
  • 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

    Добавить аргументы из предыдущей команды для завершения zsh

    Развертывание кода на связке машин

    Как выйти из полноэкранного режима в винагре?

    Можно ли просматривать носители на консоли?

    сервер osx, клиент Windows, запуск emacs открывает его на сервере, а не на клиенте

    Как подключиться к скрытой сети с помощью nmcli?

    текстовый файл с удаленным запросом, связанный с экземпляром vi

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

    Мера сетевого трафика на долгосрочной основе

    Что такое имя / подразделение systemd для установки записей fstab

    sed или tr однострочный, чтобы удалить все числовые цифры

    Как выполнить команду в каждом подкаталоге?

    Как отключить сетевые интерфейсы от загрузки при загрузке без Network Manager?

    Как просмотреть доступные параметры gsettings?

    Почему rsync пытается скопировать файл, который уже обновлен?

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