Pull to refresh

Comments 28

Это перевод, но тем не менее, да, подробное описание, интересные инструменты. Хоть это и не общеприменимый гайд, а конкретный пример, все равно полезно.
Есть более удобный способ посмотреть WCHAN, не дергая ps сто раз: top, жмем «f», выбираем WCHAN, жмем пробел, чтобы выделить его и выходим по ESC.

И получаем в итоге:
Так что, процессы не зависают сами по себе, и у зависаний всегда есть причина!?
Да. Только она, на самом деле, не всегда жизненно интересна.
Тут дядька поупражнялся-поупражнялся, да в итоге и жахнул kill -9. Я могу сделать (и скорее всего сделал бы) ровно то же самое и без шатаний по стеку ядра. Типа, скальпель не помог, давай кувалду!
Но в случае удалённой отладки/разработки с целью устранения багов, подход весьма хорош!
Спасибо, статья хорошая. А вот что виновато nfs я понял сразу после того, как увидел 'D'. Подвисающий неубиваемый процесс, который ничем не занимается может заниматься только одним — тупить в цветоче в NFS. Все остальные сетевые файловые системы менее процессораздирающие.
Ну не обязательно NFS. Может залипнуть и на любой другой FS из-за жесткого диска или бага FS. Сам я правда не сталкивался, от коллег слышал.
Залипания из-за глюков на диске обычно очень хорошо видны — страшный срач в dmesg'е. Другие сетевые fs тоже обычно имеют явные средства диагностики. Только nfs отличается молчаливым режимом «японского партизана, сражающегося 40 лет спустя после капитуляции страны».
спасибо огромное автору за статью, подчерпнул для себя пару интересных моментов, о которых еще не знал, век живи — век учись )
А с какой стороны копать, если приложение автоматически закрывается и в консоль печатается слово Killed?
Я купил NAS: Seagate Central
Внутри оказался Cavium Econa CNS3420 SoC
Есть доступ по SSH, root. Установлен Montavista Linux
Более опытные чем я люди с компилированием софта под этого зверя обломались
Я нашел там mono — проверил, программы на .net 2 нормально исполняются :)
Есть python… много чего есть. Но gcc нет :(

Диск интересно размечен:
Partition Table: gpt

Number Start End Size File system Name Flags
1 1049kB 22.0MB 21.0MB ext2 Kernel_1
2 22.0MB 43.0MB 21.0MB ext2 Kernel_2
3 43.0MB 1117MB 1074MB ext4 Root_File_System_1
4 1117MB 2190MB 1074MB ext4 Root_File_System_2
5 2190MB 3264MB 1074MB ext4 Config
6 3264MB 4338MB 1074MB linux-swap(v1) Swap
7 4338MB 5412MB 1074MB ext4 Update
8 5412MB 3001GB 2995GB Data lvm

И руководства, как пользоваться устройством «по назначению» пока нет.
Куда копать? Чего читать/качать/ставить/запускать?
посмотрите в syslog
часто такое соощение выдается в случаи если память закончилась и oom killer грохает процесы
Да мне для начала что-нибудь скомпилить надо.
Я надеялся, что в природе есть способ скомпилировать что-нибудь и без особых проблем.
Ищите тулчейн для вашей железки. Скорее всего где-нибудь на форумах поддержки нароете!
Посмотрите uname -a — очень часто в отпечатке ядра остаётся «автограф» от системы, где его собирали (вроде red hat, debian или ubuntu). А потом гуглите по сочетанию имени железки + найденного отпечатка + слов вроде «toolchain» или «cross toolchain».
Универсального рецепта нет!
Попробуйте начать с того, чтобы запустить hello world собранный статически любым компилятором для arm linux.
Dmesg можно для начала посмотреть. Ну и более общие логи, вроде /var/log/syslog или /var/log/messages.
Возможно, ошибка с выравниванием или неправильная архитектура бинарника. Я бы запустил приложение из gdb и посмотрел, где оно упадёт.
У Вас что-то с примером про strace/pstack — оба вывода одинаковые. Может напутали что-то?
Хорошая статья, спасибо!

Можете подсказать, имеются ли готовые утилиты для лёгкого профилирования всего ядра Linux, а не конкретных модулей/процессов?
Интересуют решения, работающие в x86_64 архитектуре.

Пример, чего хотелось бы видеть в качестве output'а утилиты:

3032 conntrack_mt_origsrc
1053 pppoe_seq_next
560 pppox_sock
32 something_else
31 something_else2
10 __etc

Просто боюсь, что скоро без такой утилиты у встанет работа и придётся её писать самому. :)
C этим на linux проблема. Я работаю с HP-UX, там есть такая профилировка. По окончании каждого тайм слайса генерится per cpu эвент и в ring buffer скидывается чем занимался процессор (PID, функция ядра, стек !). Очень полезная функция для изучения чем занимаются процессоры. На Linux, насколько знаю, код в ядре для реализации есть, но с утилитами дефицит.
Везёт вам! Я вот всё не дойду до того чтобы perf посмотреть.
Походу придётся адовыми хаками на nmi_timer вешаться и через dmesg, через dmesg, да башем агрегировать. :)
Похоже, сама команда strace тоже зависла!


Потому что strace'у нужно переключать контекст на трассируемую программу. Потому что в Linux нет трассировщика, который бы получал данные о syscall'ах напрямую из ядра. В *BSD есть ktrace для этих целей. Задачи из статьи им решаются очень быстро и без риска уронить процесс.

Однако, много интересного узнал о /proc. Надо будет сравнить с FreeBSD.
Объясните, пожалуйста, почему 2.6.3х является актуальным ядром?
Я бы даже поправил слегка — это актуальная версия ядра Red Hat, а потому — единственная стабильная версия (в умах многих людей).
Учитывая его стабильность, актуальность фич и фиксов, срок поддержки дистрибутивов на этом ядре…
Для продакшена альтернатив особо и нет.
странно, у меня пока ни одного процесса в непрерывном D состоянии убить kill-ом не получилось (даже с -9)
есть какой-то секрет? :)
Автору, огромное спасибо! Уйдет в документацию саппорта.
Only those users with full accounts are able to leave comments. Log in, please.