Отладка задержки ввода-вывода в Linux

Question

У меня проблемы с вводом / выводом в нескольких системах Linux, которые я администрирую. Они проявляются в том, что процессы часто блокируются на несколько секунд в таких простых системных вызовах, как open(), unlink() или close() для файлов (что является проблемой, потому что некоторым задействованным программам требуется довольно низкая задержка ввода-вывода для работы должным образом). Это правда, что рассматриваемые системы испытывают некоторую умеренную нагрузку ввода-вывода, но вряд ли я думаю, что этого будет достаточно, чтобы оправдать такое огромное время ожидания. Иногда для завершения вызовов может потребоваться более 15 секунд (хотя чаще они могут занимать 1, 2 или 3 секунды или около того).

Мой вопрос: как я могу узнать, почему это происходит? Что мне хотелось бы, так это какой-нибудь инструмент, который мог бы сказать мне, какие процессы в ядре заблокированы, и почему то, на чем они спят, занято, что с ним происходит, и тому подобное. Существует ли такой инструмент или есть какой-то другой способ отладки того, что происходит?

С другой стороны , конечно, если у вас есть какие - либо подсказки относительно того , что на самом деле происходит, как он может избежать?

Для записи, файловая система, которую я использую - XFS.

Answer 1

Теперь в свое время мне удалось решить это самому, поэтому я могу, по крайней мере, сам следить за этим для потомков.

К сожалению, я потерял исходную проблему при обновлении ядра, но вместо этого получил новую, еще хуже по производительности и такую же сложную для поиска. Методы, которые я нашел, были следующие:

Прежде всего, blktrace/blkparse - инструмент, который я нашел довольно полезным. Он позволяет отслеживать ход выполнения отдельных запросов ввода-вывода с помощью множества полезных деталей, например, процесса, который отправил запрос. Полезно поместить выходные данные в tmpfs , чтобы обработка хранилища трассировки не начинала сама себя.

Это помогло только пока, поэтому я скомпилировал ядро с большей функциональностью отладки. В частности, я нашел ftrace весьма полезным, поскольку он позволил мне отследить плохо работающий процесс в пространстве ядра, посмотреть, что он сделал и где он заблокирован. Компиляция отладочного ядра также обеспечивает работающий вывод WCHAN для ps , который может работать как более простой способ увидеть, что процесс делает внутри ядра, по крайней мере, для более простых случаев.

Я также надеялся, что LatencyTop будет полезен, но я нашел его довольно глючным, а также, что он отображал только причины задержки, которые были слишком «высокого уровня», чтобы быть действительно полезными, к сожалению.

Кроме того, я нашел более полезным, чем iostat просто просматривать содержимое /sys/block/$DEVICE/stat через очень короткие промежутки времени, просто так:

while :; do cat /sys/block/sda/stat; sleep .1; done

См. Documentation/iostats.txt в дереве исходного кода ядра для формата файла stat . Просмотр через короткие промежутки времени позволил мне увидеть точное время и размер пакетов ввода-вывода и тому подобное.

В конце концов, я обнаружил, что проблема, возникшая после обновления ядра, была вызвана стабильными страницами, функцией, появившейся в Linux 3.0, которая в моем случае приводила к остановке Berkeley DB на длительные периоды времени при загрязнении страниц в mmap'е. региональные файлы. Несмотря на то, что кажется возможным исправить эту функцию, а также то, что проблемы, которые она вызывает, могут быть исправлены в Linux 3.9, я решил наихудшую проблему, с которой я столкнулся на данный момент, исправив Berkeley DB, чтобы позволить мне помещать файлы его регионов в другой каталог. (в моем случае /dev/shm), что позволяет мне полностью избежать этой проблемы.

Answer 2

Думаю, я бы упомянул strace, хотя этому вопросу уже несколько месяцев. Это может помочь кому-то с подобной проблемой, кто находит эту страницу.

пытаться.

strace "application"

Вы также можете сделать

strace -e read,write "application"

просто показать события чтения / записи.

Приложение будет загружаться как обычно (хотя и немного медленнее при запуске), и вы можете использовать его как обычно, чтобы вызвать проблему. Вывод появится в оболочке, которую вы использовали для запуска strace.

Хорошая вещь о strace заключается в том, что вы можете видеть самый последний вызов функции / ядра в тот момент, когда приложение вызывает замедление. Вы можете обнаружить, что если ваши /home учетные записи находятся в NFS, то по какой-то причине приложение испытывает некоторые трудности с файловым вводом-выводом через NFS.

Answer 3

Согласно моему опыту, самый простой и подробный инструмент статистики, который вы можете установить для отслеживания загадочных проблем с производительностью системы, - это http://freecode.com/projects/sysstat aka. сар

наверняка вы также хотите посмотреть на вывод команды iostat, особенно, если ваш% iowait должен быть ниже 5-10% при нормальной загрузке системы (ниже 1,0 или около того).

Посмотрите на вывод ps, если в столбце STAT вы видите D статусов, что означает, что эти процессы заблокированы и ожидают ввода-вывода, очень вероятно аппаратная проблема с контроллером или диском, проверьте статистику SMART, а также dmesg и syslog для подсказок.

проверьте sar log и определите пиковое время, если это когда-либо случится, и попытайтесь сопоставить это время с интенсивными дисковыми заданиями cron, например, резервными копиями по сети

Вы можете сравнить производительность вашего диска с Bonnie ++