Вопросы Теги

Дисковые IO задержки меры рабочего процесса

Необходимо знать, где сократить. Для двоичных файлов это обычно означает знать размер FileA или FileB.

Можно найти размер FileA с ls -l. Если необходимо записать портативный сценарий, можно извлечь размер с ls -lgo FileA | awk '{print $3; exit}' (или, для non-POSIX-compliant версий ls это не имеет -g и -o опции, ls -l FileA | awk '{print $5; exit}'). На невстроенном Linux более простой способ получить размер stat -c %s FileA.

После того как у Вас есть размер, можно использовать tail извлечь вторую часть файла:

tail -c +$((sizeA + 1)) <FileC

Если Вы хотите повредить файл в равные блоки, используйте split команда.

7
21.04.2013, 19:29
2 ответа

Это на самом деле сложно. Но существуют подсказки:

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

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

Да strace может не быть соответствующим, так как это проследит все (весь syscalls, даже когда Вы используете -e фильтр), и значительно загрузит сервер и более медленный процесс. Perf очень неясный инструмент, у Вас могут быть моменты, Вы думаете, что понимаете его вывод, но Вы на самом деле не сделали, и его набор функций, высоко зависят от версии ядра. В основном и в настоящее время perf подходит для измерения процессорного времени (циклы) и [все же] является неподходящим к измерению reponse времена (в котором Вы на самом деле нуждаетесь). Я слышал, что они хотели реализовать что-то для упрощения этого, таким образом, на ядрах очень последней разработки там может иметь что-то. (Посмотрите также в сценариях перфекта (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();
7
27.01.2020, 20:17
  • 1
    Спасибо, похоже, что там существует несколько опций. Я запустил с blktrace, который кажется, что он, как предполагается, делает то, что я хочу, но я не мог получить-t опцию работать. Я посмотрю на другие также. –  ajduff574 22.04.2013, 17:57
  • 2
    Интересный подход там brendangregg.com/blog/2014-07-01/perf-heat-maps.html –  catpnosis 02.07.2014, 16:35

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

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

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

# сервисный системный журнал останавливает эхо # 1>/proc/sys/vm/block_dump

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

# сервисный системный журнал запускает эхо # 0>/proc/sys/vm/block_dump

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

# dmesg | awk '/(READ|WRITE|dirtied) / {действие [1$] ++} КОНЕЦ {для (x в действии) печатают x, действие [x]}' | вид - номер-k 2,2 | главный-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 наутилусов (24498): 46

Вывод в качестве примера выше показывает лучшие 10 процессов, которые выпустили ЧТЕНИЕ, ЗАПИШИТЕ и dirtied операции в течение времени, которое выполнял дамп блока. Используя эти данные выходит обзор высокого уровня количества операционных процессов, может быть собран, и это может помочь определить, способствует ли единственный процесс высоко iowait.

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

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

2
27.01.2020, 20:17
  • 1
    Похоже, что ни один из тех не заставит меня достаточно информации делать гистограмму. Я конкретно интересуюсь распределением времени ожидания, а не совокупное время ожидания. –  ajduff574 21.04.2013, 21:32
  • 2
    /proc/pid/stat должен все еще помочь, Вам просто был бы нужен сценарий, чтобы периодически работать и записать информацию, вычитая значение, которое было найдено в прошлый раз. После этого Вы в значительной степени берете о частоте дискретизации. –  Bratchley 22.04.2013, 00:25

Теги

Похожие вопросы