Отбор пробных звонков в Erlang

В настоящее время я изучаю проблему производительности в большом приложении Erlang. Приложение демонстрирует большую нагрузку процессора, чем ожидалось. Чтобы получить первое представление о том, какие части системы отвечают за нагрузку, я хотел бы выполнить выборку вызова, как описано в this answer.Отбор пробных звонков в Erlang

Есть ли лучший способ сделать это, чем многократно называть erlang:process_info(Pid, backtrace) и выполнять функции с этого выхода?

Обратите внимание, что система слишком велика, чтобы использовать fprof, и что etop не указал меня в правильном направлении. Использование fprof для некоторых частей системы также невозможно сейчас, так как мне сначала нужно указать общее местоположение проблемы с производительностью.

источник

2017-02-15 evnu

Я не знаю Эрланг, но я знаю эту технику. Можете ли вы запустить свою программу под отладчиком, вручную приостановить ее и проверить стек вызовов? Я бы не стал беспокоиться о том, чтобы сначала найти общее местоположение проблемы с производительностью, потому что, если для этого требуется большой процент времени, это вероятность того, что вы это увидите, и если это займет небольшой процент, скорее всего, вы еще не подозревали занимает большой процент. –

@MikeDunlavey благодарит за предложение (я только что узнал, как приостановить и возобновить процессы в Erlang из-за этого). Хотя Erlang позволяет приостановить процессы, я пока не вижу возможности упростить выборку callstack. С помощью 'erlang: process_info (Pid, backtrace)', я могу получить трассировки стека во время выполнения и не нуждаюсь в приостановке процессов самостоятельно. Но тогда я остаюсь с разбором этого вывода. – evnu

Важно * не * поставить выборку в код. Это должно произойти в то время, которое непредсказуемо с точки зрения программы. Другое дело, что вам не нужно много образцов (вопреки широко распространенному предположению). Вам нужно только дважды увидеть проблему, чтобы знать, что она стоит исправления, а среднее количество образцов, необходимых для этого, - 2/size_of_problem. Поэтому, если проблема стоит 30% времени, среднее число образцов, необходимых для ее просмотра дважды, составляет 2/0,30 = 6,67 выборок. –

Простым способом получения фактического размера стека является process_info(Pid, stack_size). Хотя это только возвращает размер стека словами, это очень простой и эффективный способ увидеть, какие процессы имеют большие стеки.

источник

2017-02-20 14:26:00 rvirding

Не будет ли «сокращение» лучшим мерилом для определения происхождения большой нагрузки? Я ожидал бы, что процессы, накладывающие большую нагрузку на систему, будут отображать постоянно большое количество «сокращений». Предварительные тесты с 'stack_size' были неубедительными (или я неверно истолковал числа) – evnu

Да,« сокращения »были бы лучшей мерой, но это был комментарий, исходный вопрос, спрашивающий об альтернативе« backtrace ». – rvirding

ответ

Смежные вопросы