-spec bin_leak(pos_integer()) -> [proc_attrs()].

Refc binaries can be leaking when barely-busy processes route them around and do little else, or when extremely busy processes reach a stable amount of memory allocated and do the vast majority of their work with refc binaries. When this happens, it may take a very long while before references get deallocated and refc binaries get to be garbage collected, leading to Out Of Memory crashes. This function fetches the number of refc binary references in each process of the node, garbage collects them, and compares the resulting number of references in each of them. The function then returns the N processes that freed the biggest amount of binaries, potentially highlighting leaks.

-spec inet_count(AttributeName, Num) -> [inet_attrs()]
              when
                  AttributeName :: recv_cnt | recv_oct | send_cnt | send_oct | cnt | oct,
                  Num :: non_neg_integer().

Fetches a given attribute from all inet ports (TCP, UDP, SCTP) and returns the biggest Num consumers.

-spec inet_window(AttributeName, Num, Milliseconds) -> [inet_attrs()]
               when
                   AttributeName :: recv_cnt | recv_oct | send_cnt | send_oct | cnt | oct,
                   Num :: non_neg_integer(),
                   Milliseconds :: pos_integer().

Fetches a given attribute from all inet ports (TCP, UDP, SCTP) and returns the biggest entries, over a sliding time window.

Warning: this function depends on data gathered at two snapshots, and then building a dictionary with entries to differentiate them. This can take a heavy toll on memory when you have many dozens of thousands of ports open.

-spec info(pid_term()) -> [{info_type(), [{info_key(), Value}]}, ...] when Value :: term().

Allows to be similar to erlang:process_info/1, but excludes fields such as the mailbox, which have a tendency to grow and be unsafe when called in production systems. Also includes a few more fields than what is usually given (monitors, monitored_by, etc.), and separates the fields in a more readable format based on the type of information contained.

-spec info(pid_term(), info_type()) -> {info_type(), [{info_key(), term()}] | undefined};
    (pid_term(), [atom()]) -> [{atom(), term()}] | undefined;
    (pid_term(), atom()) -> {atom(), term()} | undefined.

Allows to be similar to erlang:process_info/2, but allows to sort fields by safe categories and pre-selections, avoiding items such as the mailbox, which may have a tendency to grow and be unsafe when called in production systems.

Moreover, it will fetch and read information on local processes that were registered locally (an atom), globally ({global, Name}), or through another registry supported in the {via, Module, Name} syntax (must have a Module:whereis_name/1 function). Pids can also be passed in as a string ("<0.39.0>") or a triple ({0,39,0}) and will be converted to be used.

Although the type signature doesn't show it in generated documentation, a list of arguments or individual arguments accepted by erlang:process_info/2 and return them as that function would.

-spec node_stats(N, Interval, FoldFun, Acc) -> Acc
              when
                  N :: non_neg_integer(),
                  Interval :: pos_integer(),
                  FoldFun :: fun((Stats, Acc) -> Acc),
                  Acc :: term(),
                  Stats :: {[Absolutes :: {atom(), term()}], [Increments :: {atom(), term()}]}.

Gathers statistics N time, waiting Interval milliseconds between each run, and accumulates results using a folding function FoldFun. The function will gather statistics in two forms: Absolutes and Increments.

Absolutes are values that keep changing with time, and are useful to know about as a datapoint: process count, size of the run queue, error_logger queue length in versions before OTP-21 or those thar run it explicitly, and the memory of the node (total, processes, atoms, binaries, and ets tables).

-spec port_info(port_term()) -> [{port_info_type(), [{port_info_key(), term()}]}, ...].

Allows to be similar to erlang:port_info/1, but allows more flexible port usage: usual ports, ports that were registered locally (an atom), ports represented as strings ("#Port<0.2013>"), or through an index lookup (2013, for the same result as "#Port<0.2013>").

Moreover, the function will try to fetch implementation-specific details based on the port type (only inet ports have this feature so far). For example, TCP ports will include information about the remote peer, transfer statistics, and socket options being used.

-spec port_info(port_term(), port_info_type()) -> {port_info_type(), [{port_info_key(), _}]};
         (port_term(), [atom()]) -> [{atom(), term()}];
         (port_term(), atom()) -> {atom(), term()}.

Allows to be similar to erlang:port_info/2, but allows more flexible port usage: usual ports, ports that were registered locally (an atom), ports represented as strings ("#Port<0.2013>"), or through an index lookup (2013, for the same result as "#Port<0.2013>").

-spec proc_window(AttributeName, Num, Milliseconds) -> [proc_attrs()]
               when
                   AttributeName :: atom(),
                   Num :: non_neg_integer(),
                   Milliseconds :: pos_integer().

Fetches a given attribute from all processes (except the caller) and returns the biggest entries, over a sliding time window.

This function is particularly useful when processes on the node are mostly short-lived, usually too short to inspect through other tools, in order to figure out what kind of processes are eating through a lot resources on a given node.

It is important to see this function as a snapshot over a sliding window. A program's timeline during sampling might look like this:

--w---- [Sample1] ---x-------------y----- [Sample2] ---z--->

Some processes will live between w and die at x, some between y and z, and some between x and y. These samples will not be too significant as they're incomplete. If the majority of your processes run between a time interval x...y (in absolute terms), you should make sure that your sampling time is smaller than this so that for many processes, their lifetime spans the equivalent of w and z. Not doing this can skew the results: long-lived processes, that have 10 times the time to accumulate data (say reductions) will look like bottlenecks when they're not one.

-spec remote_load(module()) -> term().

Equivalent to remote_load(nodes(), Mod).

-spec scheduler_usage(Millisecs) -> undefined | [{SchedulerId, Usage}]
                   when
                       Millisecs :: non_neg_integer(),
                       SchedulerId :: pos_integer(),
                       Usage :: number().

Because Erlang CPU usage as reported from top isn't the most reliable value (due to schedulers doing idle spinning to avoid going to sleep and impacting latency), a metric exists that is based on scheduler wall time.

For any time interval, Scheduler wall time can be used as a measure of how 'busy' a scheduler is. A scheduler is busy when:

• executing process code
• executing driver code
• executing NIF code
• executing BIFs
• garbage collecting
• doing memory management