Fri May 30 23:36:18 CEST 2003
You could also look at run_queue, which should normally be quite small.
Of course, if you have one process doing tons of work, reductions will give
you a better indicator. A combination of indicators is usually needed to get
a good reading on processor load. In an I/O-bound system, run_queue is
pretty good. In a CPU-bound system, reductions may work.
But I would not go as far as waiting for reductions to be unchanged for one
second. That may never happen. I think you should track these indicators for
a while and try to determine what thresholds seem sensible.
cpu_sup.erl may also be used for some perfmeter-like load measurements.
----- Original Message -----
From: "Eric Newhuis" <>
Sent: den 29 maj 2003 19:17
Subject: Idleness Signal
> I have a "time trial" test whereby I cram a bunch of data into a
> multi-process single-node Erlang application and then wait for things to
> "settle down".
> The application has a lot of messaging and I do not wish to intrude on
> the messaging pipeline to determine an exact event-driven completion
> signal. My goal is to determine the total cost of processing my batch
> of input messages and to compare the various run times among different
> algorithms, data structures, optimizations, etc.
> I also intend to use eprof to investigate with finer granularity to help
> explain differences in "time trial" results. So I am not seeking a
> substitute for eprof. I love eprof. I am building a complimentary tool.
> Can anyone suggest alternatives for raising a signal that says that an
> Erlang node is idle?
> I am currently entertaining the thought of polling the total REDS, as
> seen in erl's i() output and terminating my test when the REDS is
> unchanged for 1 second. Since I think I am all CPU bound during this
> test I think this will work. (I/O-bound conditions may effect false
> Is there a more clever way to raise such a signal? ...more clever than
> polling REDS? I don't need precision beyond 1 second; my time trial is
> expected to run for several minutes to an hour.
> Eric Newhuis
More information about the erlang-questions