[erlang-questions] Percept profiler

[Andreas Hillqvist]

I got in contact with Björn-Egil Dahlberg, who wrote a thesis on
"Profiling applications in Erlang Symmetrical MultiProcessing system".
I do not believe the thesis is public available. But you can find an
early draft online:
http://www.cs.umu.se/~tm99bdg/documents/thesis-v.0.3.pdf

I sent an e-mail to, Björn-Egil Dahlberg, he gave my some insights.

I have translated his answer from Swedish:
-----Original Message-----
From: Björn-Egil Dahlberg
Sent: 2007-11-13 16:56

Profiling is activated though a special BIF, erlang:system_profile/2.
Through it you could specify if you would like to monitor Erlang
process, ports or schedule threads.

Through monitoring Erlang process you could measure parallelity in
your applications and hopfully identify bottlenecks in your system. It
dose not state how well erts utilize the CPUs. For that you could use
the scheduler.

The monitoring is performed by identifying parallel primative (send,
receive, spawn, suspend, etc) in the runtime system. When a event is
triggered by a matching state transition a message together with a
time stamp and MFA is sent to the Pid/Port you have assigned as
listener. This is similar to erlang:trace.

I(Björn-Egil) have made a rugh simplification and divided the process
states into two parallel states: running, runnable, exiting -> active,
waiting, suspend -> inactive

system_profile(Pid, [scheduler]) monitors the scheduler (Those threads
that are actually running Erlang processes on the OS).
They are often mapped 1-1 against the number of processors/cores that
exist on the system. (But some problems still persist)

Evan ports may be monitored, but this is not as interesting. Some
callbacks are queued and are considered as runnables (active), when
they run (active) and i other case non running (inactive).

There will be a new OTP-application , Percept. Percept stands for,
Percept - Erlang Concurrency Profiling Tool.
The thought behind it was to offer a better overview of the data.
Amongst other through graphs parallelity over time.
-----End Original Message-----

I have not tried Percept, yet. I think this tool will be useful to
help you find bottle necks.
I.e. Many "worker" process waits for a single server/process to reply.


Kind regards
Andreas Hillqvist

2007/12/14, Joel Reymont <joelr1@REDACTED>:
> I see documentation on the Percept profiler API but could someone
> explain the purpose of this tool?
>
> What is a "Concurrency Profiler"?
>
> When and where should it be used?
>
>         Thanks, Joel
>
> --
> http://wagerlabs.com
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>