Профилирование запросы Mnesia

Поскольку запросы Mnesia - это просто функции Erlang, я полагаю, вы можете профилируйте их так же, как вы бы профилировали свой собственный код Erlang. http://www.erlang.org/doc/efficiency_guide/profiling.html#id2266192 содержит дополнительную информацию о доступных инструментах профилирования erlang.

Обновление В качестве теста я запускал это дома на тестовом экземпляре mnesia и с помощью fprof для трассировки mnesia qlc-запроса вернул результат, образец которого я включаю ниже. Таким образом, он определенно включает больше информации, чем просто вызов запроса.

....
{[{{erl_lint,pack_errors,1},                      2,    0.004,    0.004}],     
 { {lists,map,2},                                 2,    0.004,    0.004},     %
 [ ]}.

{[{{mnesia_tm,arrange,3},                         1,    0.004,    0.004}],     
 { {ets,first,1},                                 1,    0.004,    0.004},     %
 [ ]}.

{[{{erl_lint,check_remote_function,5},            2,    0.004,    0.004}],     
 { {erl_lint,check_qlc_hrl,5},                    2,    0.004,    0.004},     %
 [ ]}.

{[{{mnesia_tm,multi_commit,4},                    1,    0.003,    0.003}],     
 { {mnesia_locker,release_tid,1},                 1,    0.003,    0.003},     %
 [ ]}.

{[{{mnesia,add_written_match,4},                  1,    0.003,    0.003}],     
 { {mnesia,add_match,3},                          1,    0.003,    0.003},     %
 [ ]}.

{[{{mnesia_tm,execute_transaction,5},             1,    0.003,    0.003}],     
 { {erlang,erase,1},                              1,    0.003,    0.003},     %
 [ ]}.

{[{{mnesia_tm,intercept_friends,2},               1,    0.002,    0.002}],     
 { {mnesia_tm,intercept_best_friend,2},           1,    0.002,    0.002},     %
 [ ]}.

{[{{mnesia_tm,execute_transaction,5},             1,    0.002,    0.002}],     
 { {mnesia_tm,flush_downs,0},                     1,    0.002,    0.002},     %
 [ ]}.

{[{{mnesia_locker,rlock_get_reply,4},             1,    0.002,    0.002}],     
 { {mnesia_locker,opt_lookup_in_client,3},        1,    0.002,    0.002},     %
 [ ]}.

{[ ],
 { undefined,                                     0,    0.000,    0.000},     %
 [{{shell,eval_exprs,6},                          0,   18.531,    0.000},      
  {{shell,exprs,6},                               0,    0.102,    0.024},      
  {{fprof,just_call,2},                           0,    0.034,    0.027}]}.

Я воздержался, потому что я мало что знаю ни об Erlang, ни о Mnesia, но я много знаю о настройке производительности, и из обсуждения пока это звучит довольно типично. инструменты fprof и т. д. звучат как большинство инструментов, которые заимствуют свой фундаментальный подход из gprof , а именно инструментальные функции, подсчет вызовов, выборку счетчика программ и т.д. основы этой практики в течение длительного времени. Ваше разочарование звучит типично для пользователей подобных инструментов.

Есть менее известный метод, который вы могли бы рассмотреть , изложенный здесь . Он основан на взятии небольшого числа (10-20) выборок состояния программы в случайные моменты времени и на понимании каждой из них, а не на обобщении. Обычно это означает изучение стека вызовов, но вы можете захотеть изучить и другую информацию. Есть разные способы сделать это, но я просто использую кнопку паузы в отладчике. Я не пытаюсь узнать точное время или количество вызовов. В лучшем случае это косвенные подсказки. Вместо этого я спрашиваю каждый образец «Что он делает и почему?» Если я обнаруживаю, что он выполняет какое-то конкретное действие, например, выполняет X-запрос, в котором он ищет ответ типа y для цели z, и он делает это более чем на одном образце, тогда доля образцов, на которых он это делает, является приблизительной, но надежной оценкой того, в какой части времени он это делает. Скорее всего, я могу что-то с этим поделать и получить хорошее ускорение.

Вот пример использования этого метода.

Mike Dunlavey's suggestion reminds me about redbug that allow you to sample calls in production systems. Think of it as an easy-to-use erlang:trace that doesnt give you enough rope to hang your production system.

Using something like this call should give you lots of stack traces to identify where your mnesia transactions are called from:

redbug:start(10000,100,{mnesia,transaction,[stack]}).

Its not possible to get call duration for these traces though.

If you have organized all mnesia lookups into modules that export an api to perform them, you could also use redbug to get a call-frequency on specific queries only.