Proposal: process_info(Pid, start_time)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: process_info(Pid, start_time)

Danil Zagoskin-2
Hi!

TL;DR: Would you like to know when any process was started in little cost of memory usage on 32-bit systems and crashdump generation speed?

Sometimes we have to inspect long-running systems.
And if a complex enough system runs for a month, it's hard to answer these questions:
 - Process A should run at most 1 hour. Did it stall a week ago?
 - Process B is supervised and it's not good when it restarts. Did it restart last night?
 - Did process C exist when process D was started?
 - Was pid E reused by a new process since it was stored in ETS?

To answer that questions we need a process start time to be stored somewhere.
Given that almost every project uses third-party libraries with their own processes, the universal solution could be having process start time available in process_info.

It turned out that ERTS already have a process start time, used by a crashdump writer.

I proposed a PR exposing that value in process_info: https://github.com/erlang/otp/pull/1597
It's very simple — just return a value we already have.

But as Rickard Green noticed, it's better to have this time as Erlang monotonic time instead of system seconds in current implementation.
This will slightly increase memory consumption on 32-bit systems and slightly slow down crashdump generation.

The other option Rickard proposed is to remove that timestamp completely and save some memory.


So, the questions are:

 - Do you find process_info(Pid, start_time) useful and worth 4 bytes/process on 32 bit systems?
 - Do you find process start time in a crashdump useful?

--
Danil Zagoskin | [hidden email]

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: process_info(Pid, start_time)

Vladimir Gordeev
Good feature.

Currently I'm trying to build a trace visualization tool, and such information would be quite useful.
It would allow to explore in what order different parts of the system were started.

Also +1 for monotonic timestamp, that would allow to consistently put it along other trace timestamps.


On Mon, Oct 9, 2017 at 5:20 PM, Danil Zagoskin <[hidden email]> wrote:
Hi!

TL;DR: Would you like to know when any process was started in little cost of memory usage on 32-bit systems and crashdump generation speed?

Sometimes we have to inspect long-running systems.
And if a complex enough system runs for a month, it's hard to answer these questions:
 - Process A should run at most 1 hour. Did it stall a week ago?
 - Process B is supervised and it's not good when it restarts. Did it restart last night?
 - Did process C exist when process D was started?
 - Was pid E reused by a new process since it was stored in ETS?

To answer that questions we need a process start time to be stored somewhere.
Given that almost every project uses third-party libraries with their own processes, the universal solution could be having process start time available in process_info.

It turned out that ERTS already have a process start time, used by a crashdump writer.

I proposed a PR exposing that value in process_info: https://github.com/erlang/otp/pull/1597
It's very simple — just return a value we already have.

But as Rickard Green noticed, it's better to have this time as Erlang monotonic time instead of system seconds in current implementation.
This will slightly increase memory consumption on 32-bit systems and slightly slow down crashdump generation.

The other option Rickard proposed is to remove that timestamp completely and save some memory.


So, the questions are:

 - Do you find process_info(Pid, start_time) useful and worth 4 bytes/process on 32 bit systems?
 - Do you find process start time in a crashdump useful?

--
Danil Zagoskin | [hidden email]

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions