[erlang-questions] Enhancement to erlang:system_info ?

[Chris Newcombe]

Hello OTP team,

I'm writing a memory-bounds feature for my system.   (Erlang is fantastic in
this regard -- it's wonderful to be able to examine memory-usage stats for
individual or groups of processes, and perhaps force them to garbage-collect
or even kill them, causing the minimum transitive restart via supervisors.
I'm using Ulf's gproc library to classify processes by type, and prioritize
them, so I can mimimize intrusiveness when choosing which processes to
kill.)

Part of this mechanism uses erlang:system_info with the 'large_heap' option
-- that's a great facility.

But I'm really missing a similar facility for detecting runaway creation of
binaries.

Please would you consider adding a 'large_binaries' option to
erlang:system_info?
This would send a message if a process allocates more than a total of N
bytes of binaries.

Of course, one issue with that is what does "allocate" mean when multiple
processes can have references to the same binary?

As erlang:system_info seems best for coarse-grain alarms, I think it would
work fine if the event was triggered when a process was simply holding
references to more than N bytes of binary data, even if other processes had
references to some of that data.    (The threshold should include the
'buffer' at the end of each binary -- e.g. the Efficiency Guide mentions
that most short binaries actually allocate 256 bytes, incase they grow.)

If such a feature is not acceptable/possible, would you consider adding a
'large_total_binaries' option?
This would send a message if the total size of all binaries in the VM
crossed a threshold.  (I know I can poll for that via erlang:memory(binary),
but binaries can be created very rapidly and I don't want to poll at some
sub-second interval.)

Many thanks,

Chris

(And congratulations on the R13A beta -- it looks fantastic!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090323/5cac9816/attachment.htm>