Конкретно этот инструмент от Марка Русиновича показывает, сколько ресурсов центрального процессора должен занимать процесс и какое время должно пройти, прежде чем ProcDump создаст дамп процесса. То есть дамп записывается автоматически, когда процесс в очередной раз повысит нагрузку на центральный процессор выше определённого порога.
Например, под Windows мы хотим изучить аномальное поведение wmiprvse.exe (процесс WMI Provider Host), который в произвольные моменты времени занимает до 90% ресурсов CPU. Тогда запускаеми следующую команду, которая трижды запишет дамп этого процесса в случае, если потреблением им CPU в течение трёх секунд превышает 80%.
procdump.exe -c 80 -s 3 -n 3 wmiprvse Действительно, очень удобно.
Версия под Linux работает примерно так же, как под Windows, разве что опций в программе поменьше:
Usage: procdump [OPTIONS...] TARGET
OPTIONS
-C CPU threshold at which to create a dump of the process from 0 to 100 * nCPU
-c CPU threshold below which to create a dump of the process from 0 to 100 * nCPU
-M Memory commit threshold in MB at which to create a dump
-m Trigger when memory commit drops below specified MB value.
-n Number of dumps to write before exiting
-s Consecutive seconds before dump is written (default is 10)
TARGET must be exactly one of these:
-p pid of the process
-w Name of the process executableВ данный момент поддерживается работа только на ядре 3.5 или более старшей версии.
Комментарии (33)
mikevmk
05.11.2018 15:20Выпустили год назад вроде как
Сильно ли это удобнее пары строк на shell + gcore — не совсем ясно. Надо пробовать
iig
05.11.2018 17:22+2Почему фу? Выпустили, ну ок. Под Linux в 2018 году уже есть 100500 способов сделать странное… Вот есть и 100501-й в виде специальной программы от MS.
Просто в ОС, где доступны исходники, и за 5 мин находится решение задачи… Специально помнить, что есть такая специальная утилита, как-то сложновато.bugdesigner
06.11.2018 05:28Просто из этих 100500 способов никто не делал вид, что решена неразрешимая проблема.
some_x
06.11.2018 06:26Вообще есть много причин, например:
1) Вот я не работаю с Linux, зато утилита procump мне хорошо знакома. И если мне внезапно нужно будет отладить проблемное приложение на Linux, то проще всего мне будет начать порта хорошо знакомой мне утилиты, чем разбираться в других.
2) Как подсказывает мне интуция основанная на опыте, когда дляодной задачи есть 100500 инструментов, из них 100000 не работают, а 475 работают плохо/только с напильником/не в твоём случае.
И найти схожу эти работающие инструменты, не так уж просто.
И мне логично будет начать с procdump по причине п.1 и потому что я могу надеяться что ms не будет выпускать откровенно не рабочую утилиту.
vpiskunov
05.11.2018 20:48Microsoft вообще молодцы. Сразу понятно — кто делает у себя большой рефакторинг. Движутся в своих действиях в правильном наеоавлении, но не все сразу получится идеально.
bugdesigner
06.11.2018 05:33Чуть чаем не подавился. Мессия микрософт, как же мы без него жили то раньше? Большой рефакторинг Скайпа, например, мы уже все видели. С ужасом думаю, что будет, когда "наведут порядок" на гитхабе.
loginsin
06.11.2018 01:47Код понравился: портировали часть своего API и дальше пользуются как в нативной ОС. :-)
scruff
06.11.2018 05:49Мне не очень ясно, что делать с дампом от процесса. Возможно сравниваю тёплое с мягким, но анализируя дамп от BSOD-a, например, далеко не всегда удается понять причину сваливания системы.
some_x
06.11.2018 06:21Есть разные варианты каждый случай индивидуален.
Если мы смотрим crash dump, то в простейшем случае call stack нам покажет именно то место где упало. Примерно так же можно поступить если дамп записан по тригеру «зависание».
Если мы пишем дамп по тригеру загрузки процессора, да ещё и пишем эти дампы серией (после срабатывания тригера пишем n дампов, через каждые x секунд), то можно посмотреть какая нить в каком месте застряла.
Аналогично можно поступить с тригером потребления памяти.
Описанные способы конечно не 100% работают, но шанс есть (и иногда за него хватаешься как за соломинку).
А ещё из дампа можно извлечь специфичную для приложения/фреймворка информацию, например если мы отлаживаем дамп рабочего процесса iis, то можно посмотреть (например) какие запросы выполнялись в момент снятия дампа и как долго.
maydjin
06.11.2018 11:57Не юниксвейнинько однако.
Оно раз в n секунд просыпается? Т.е. может пропустить пик? Зачем оно тогда?
По памяти решение кажется лучше есть, например включить корки и использовать
earlyroom, который сработает как только приложение попытается выделить памяти сверх лимита.
kovserg
Круто ждём tcpdump, iotop, iftop, htop, fatrace, lspci, lsusb, lsblk и wavemon
datacompboy
А что из линуксовой аптечки умеет дамп писать по жручке сру?
skymal4ik
#!/sarcasm
Можно же собрать велосипед-однострочник из bash, top, sed, uptime и немного дебага этого всего :))
datacompboy
Ну вот не однострочник, и счастливой отладки :)
iig
while cat /proc/$PID/stat | awk '{условие срабатывания}'; do sleep 0; done; gcore $PID
Думаю, где-то так можно. А если вместо bash взять python, то оно и процессор грузить не будет.
datacompboy
вот это самое «условие срабатывания» уже не так тривиально.
а если взять вместо питона си — всё, сразу фу и не надо так?
avost
Большой разницы нет. Просто таких банальных фиговин средний админ пишет по пятьдесят штук на дню, но, отчего-то, не публикует каждую с помпой — "микросовт выпустила убер-утилиту для линукса!".
Говорят, микросовт стала самым большим контрибьютором в опенсорс. Если они вот такую банальщину контрибьютят тоннами, то это и неудивительно. Можно написать отдельные утилиты для поиска *.тхт файлов. И ещё одну для.мп3 и тд и тп. Огромный простор для засирания опенсорса никчёмным говном.
datacompboy
А, погоди, претензия-то к кому — к ализару или к мокрософту?
sumanai
Почти любой код почти на любом языке программирования можно превратить в однострочник.
grayich
atop к примеру, ну и ещё там вагон с тележкой были(не помню за ненадобностью)
… пардон, не то, был невнимателен
datacompboy
Нет такой буквы в коммандлайне атопа. Ну или ткните носом? Я даже перечитал ман уже.
gecube
А она (буква) и не нужна. Проблема atop только одна — это все-таки утилита ретроспективного анализа. И возможно, что не удастся с первого раза угадать интервал снятия метрик.
kvaps
YourChief
юзаю часто gdb для этих целей. вариантов применений масса, от ручного аттача до полуавтоматического (https://poormansprofiler.org/)
для особо тонких работ по наводке одного из хабравчан юзаю теперь вот такое: http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
первое — стандартный отладчик, второе — линуксовый профайлер в ядре со скриптом для агрегации вывода
YourChief
причём приведённые мной инструменты работают более тонко, чем procdump. второй так вообще позволяет достаточно общую количественную картину узреть.