Is there a simple way to get a list of all currently waiting timers started with erlang:send_after
, erlang:apply_after
, etc. in Erlang?
相关问题
- Is “new” in Erlang part of the official standard a
- how to create a keep-alive process in Erlang
- ejabberd and Erlang installation with lager_transf
- Encrypt (cryptojs) - Decrypt (erlang)
- How to use erlang-examples
相关文章
- How do I modify a record in erlang?
- Check active timers in Erlang
- undefined function maps:to_json/1
- How to convert datetime() to timestamp() in Erlang
- what good orm api will work well with scala or erl
- GC performance in Erlang
- When to “let it crash” and when to defend the code
- Intercept login/logout ejabberd
you could save the references returned by send_after, aply_after etc and use erlang:read_timer to check if it is still waiting (read_timer returns false if the timer has been canceled or isn't waiting anymore)
For debugging purposes you can use
dbg
:).First create an ets table which will store all timer references.
Then create a dbg handler function, which checks for calls returning from erlang:send_after, and saves the returned timer reference to the table
Set the function as trace handler. Also enable matching on the call to
erlang:send_after()
on all processesMake some test calls to
erlang:send_after()
Finally check that the table does contain those references:
This way you will store all timer references ever created by any process ever calling
erlang:send_after()
. You can map them overerlang:read_timer()
to filter the alive timers.You can trace calls to
send_after
in a similar manner. It is also possible to match oncancel_timer
and manually remove the cancelled references from the table.Also, if you don't have a message-intensive application, you should be able to match on messages and/or functions triggered by those timers, and remove the expired references from the list.
I run into the same necessity of tracking timers today.
It is on production, so I do not want to use dbg. These are erlang:timers so my previous solution is useless.
Instead I analysed nbif_timer parameter from binary_to_list(erlang:system_info(info)).
I believe (have not confirmed yet), it reports memory allocated for timers. On my system x64 it would be 17 words of 8 bytes = 136 bytes.
Monitoring this value clearly shows when system sets high number of timers.
enjoy.
thats a hack but use: ets:tab2list(timer_tab). For two timers it holds:
Looking at the code in erl_bif_timer.c I think crash dump is the only place where you can find a list of all BIF timers which were just active. :-)