Comments 34
А что из линуксовой аптечки умеет дамп писать по жручке сру?
Можно же собрать велосипед-однострочник из bash, top, sed, uptime и немного дебага этого всего :))
Ну вот не однострочник, и счастливой отладки :)
Думаю, где-то так можно. А если вместо bash взять python, то оно и процессор грузить не будет.
а если взять вместо питона си — всё, сразу фу и не надо так?
а если взять вместо питона си — всё, сразу фу и не надо так?
Большой разницы нет. Просто таких банальных фиговин средний админ пишет по пятьдесят штук на дню, но, отчего-то, не публикует каждую с помпой — "микросовт выпустила убер-утилиту для линукса!".
Говорят, микросовт стала самым большим контрибьютором в опенсорс. Если они вот такую банальщину контрибьютят тоннами, то это и неудивительно. Можно написать отдельные утилиты для поиска *.тхт файлов. И ещё одну для.мп3 и тд и тп. Огромный простор для засирания опенсорса никчёмным говном.
… пардон, не то, был невнимателен
top | grep '<pid>'
для особо тонких работ по наводке одного из хабравчан юзаю теперь вот такое: http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
первое — стандартный отладчик, второе — линуксовый профайлер в ядре со скриптом для агрегации вывода
Сильно ли это удобнее пары строк на shell + gcore — не совсем ясно. Надо пробовать
Ну, теперь заживем! Отож токмо мучились...
Просто в ОС, где доступны исходники, и за 5 мин находится решение задачи… Специально помнить, что есть такая специальная утилита, как-то сложновато.
Просто из этих 100500 способов никто не делал вид, что решена неразрешимая проблема.
1) Вот я не работаю с Linux, зато утилита procump мне хорошо знакома. И если мне внезапно нужно будет отладить проблемное приложение на Linux, то проще всего мне будет начать порта хорошо знакомой мне утилиты, чем разбираться в других.
2) Как подсказывает мне интуция основанная на опыте, когда дляодной задачи есть 100500 инструментов, из них 100000 не работают, а 475 работают плохо/только с напильником/не в твоём случае.
И найти схожу эти работающие инструменты, не так уж просто.
И мне логично будет начать с procdump по причине п.1 и потому что я могу надеяться что ms не будет выпускать откровенно не рабочую утилиту.
Microsoft вообще молодцы. Сразу понятно — кто делает у себя большой рефакторинг. Движутся в своих действиях в правильном наеоавлении, но не все сразу получится идеально.
Если мы смотрим crash dump, то в простейшем случае call stack нам покажет именно то место где упало. Примерно так же можно поступить если дамп записан по тригеру «зависание».
Если мы пишем дамп по тригеру загрузки процессора, да ещё и пишем эти дампы серией (после срабатывания тригера пишем n дампов, через каждые x секунд), то можно посмотреть какая нить в каком месте застряла.
Аналогично можно поступить с тригером потребления памяти.
Описанные способы конечно не 100% работают, но шанс есть (и иногда за него хватаешься как за соломинку).
А ещё из дампа можно извлечь специфичную для приложения/фреймворка информацию, например если мы отлаживаем дамп рабочего процесса iis, то можно посмотреть (например) какие запросы выполнялись в момент снятия дампа и как долго.
Не юниксвейнинько однако.
Оно раз в n секунд просыпается? Т.е. может пропустить пик? Зачем оно тогда?
По памяти решение кажется лучше есть, например включить корки и использовать earlyroom, который сработает как только приложение попытается выделить памяти сверх лимита.
Microsoft выпустила Linux-версию утилиты ProcDump