[erlang-questions] How to see which processes used ets table?

[ok@REDACTED]

"Björn-Egil Dahlberg" <wallentin.dahlberg@REDACTED>
wrote:
>> The problem here is that a well designed and tested system that
>> has worked flawlessly for years can stop working as a result of
>> some apparently unrelated upgrade.
>>
>
> Well, normally one tests an upgraded system before deployment but I agree
> with your point.

One would have surmised that Apple had thoroughly tested their
Java-related patches, but allegedly that's what killed NFS on my
desktop machine.  One would think that a payroll system would be
thoroughly tested before abruptly moving 110,000 teachers over to
it, but apparently four separate consultants told the New Zealand
government to go ahead with deployment despite Talent2 telling
them there were 147 known serious bugs.

There's all that "normally" stuff I tell me students to do,
and then there's what happens in the "real" world.

>> The only alternative I've been able to think of with the
>> existing interfaces is to create a watchdog process that
>> checks process_info(Target, memory) periodically, which is
>> doable, and which can check for message queue growth as well.
>>
>
> I wouldn't recommend such an approach either. Especially if you want it in
> production. You will kill any sort of performance if you do this. Also, if
> you implement something within erts that tries to check the *complete* msg
> queue (both inner and outer) you will also kill any sort of application
> performance.

This caught my eye.  What are "inner" and "outer"
message queues?  One aspect of Erlang implementation I've
never understood is how message queues actually work.
>
> I think the best approach is the garbage collector still.


Well, the EEP I posted today suggests checking memory limits
at garbage collection time.

> Also, processes is just one type of entity for limits.

True.  I've received the impression that they are the
most commonly reported kind.

You have to consider
> *all* aspects of the runtime system if you wish to make a limits proposal
> that can stop OOM problems.

That sounds reasonable, but I'm not sure that waiting until
we can guarantee to stop *all* OOM problems is better than
reducing the incidence of *some* OOM problems sooner.
>
> I'm still not convinced that this should be prioritized over something
> else. Runaway memory is, most of the time, bad flow control. Wouldn't it
> be better to solve that instead?

Perhaps I spend too much time reading the Haskell mailing list,
where runaway memory is commoner than in Erlang and has many and
subtle causes.  Perhaps I've spent too much time hacking Smalltalk,
where at least in my programs memory gets chewed up by data structures
I didn't even know were being allocated, let alone retained.

It would be *wonderful* to have clearly written advice and
supporting libraries to get flow control right.
It may well be *better* to do that first.

But it won't stop OOM problems.