Debugging Linux I/O latency
У меня проблемы с вводом / выводом в нескольких системах Linux, которые я администрирую. Они проявляются в том, что процессы часто блокируются на несколько секунд в таких простых системных вызовах, как open(), unlink() или close() для файлов (что является проблемой, потому что некоторым из участвующих программ требуется довольно низкая задержка ввода-вывода для работы должным образом). Это правда, что рассматриваемые системы испытывают некоторую умеренную нагрузку ввода-вывода, но вряд ли я думаю, что этого будет достаточно, чтобы оправдать такое огромное время задержки. Иногда для завершения вызовов может потребоваться более 15 секунд (хотя чаще они могут занимать 1, 2 или 3 секунды или около того).
Мой вопрос: как я могу узнать, почему это происходит? Что мне хотелось бы, так это какой-то инструмент, который мог бы сказать мне, какие процессы в ядре заблокированы, и почему то, на чем они спят, занято, что с ним происходит, и тому подобное. Существует ли такой инструмент или есть какой-то другой способ отладки того, что происходит?
В качестве альтернативы, конечно, если у вас есть какие-либо подсказки относительно того, что на самом деле происходит, как этого можно избежать?
Для записи, файловая система, которую я использую, - XFS.
3 ответа
Теперь в свое время мне удалось решить это самому, поэтому я могу, по крайней мере, сам следить за этим для потомков.
К сожалению, я потерял исходную проблему при обновлении ядра, но вместо этого получил новую, еще хуже по производительности и такую же сложную для поиска. Методы, которые я нашел, были следующие:
Прежде всего, 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), что позволяет мне вообще избежать этой проблемы.
Согласно моему опыту, самый простой и подробный инструмент статистики, который вы можете установить для отслеживания таинственных проблем с производительностью системы, - это http://freecode.com/projects/sysstat aka. сар
наверняка вы также хотите посмотреть на вывод команды iostat, особенно, если ваш%iowait должен быть ниже 5-10% при нормальной загрузке системы (ниже 1,0 или около того).
Посмотрите на вывод ps, если в столбце STAT вы видите D статусов, что означает, что эти процессы заблокированы и ожидают ввода-вывода, очень вероятно аппаратная проблема с контроллером или диском, проверьте статистику SMART, а также dmesg и syslog для подсказок.
проверьте sar log и определите пиковое время, если это когда-либо случится, и попытайтесь сопоставить это время с интенсивными дисковыми заданиями cron, например, резервными копиями по сети
Вы можете оценить производительность своего диска с помощью Bonnie++
Думаю, я бы упомянул strace, хотя этому вопросу уже несколько месяцев. Это может помочь кому-то с подобной проблемой, кто находит эту страницу.
пытаться.
strace "application"
Вы также можете сделать
strace -e read,write "application"
просто показать события чтения / записи.
Приложение будет загружаться как обычно (хотя и немного медленнее при запуске), и вы можете использовать его как обычно, чтобы вызвать проблему. Вывод появится в оболочке, которую вы использовали для запуска strace.
Хорошая вещь о strace заключается в том, что вы можете видеть самый последний вызов функции / ядра в тот момент, когда приложение вызывает замедление. Вы можете обнаружить, что если ваш /home учетные записи находятся в NFS, тогда приложение испытывает некоторые трудности с файловым вводом-выводом по NFS по какой-то причине.