erlang_system_info(3)

📦

version 29.0.6 · 3 versions

, in ubuntu stonking

✨ NAME ✨

erlang_system_info(3) — Returns information about the current system. 💁♀️✨

💖 DESCRIPTION 💖

The documentation of this function is broken into the following sections in order to make it easier to navigate. 🗺️💅

Memory Allocation — allocated_areas, allocator, alloc_util_allocators, allocator_sizes
CPU Topology — cpu_topology, logical_processors, update_cpu_info
Process Information — fullsweep_after, garbage_collection, heap_sizes, heap_type, max_heap_size, message_queue_data, min_heap_size, min_bin_vheap_size, procs
System Limits — atom_count, atom_limit, ets_count, ets_limit, port_count, port_limit, process_count, process_limit
System Time — end_time, os_monotonic_time_source, os_system_time_source, start_time, time_correction, time_offset, time_warp_mode, tolerant_timeofday
Scheduler Information — dirty_cpu_schedulers, dirty_cpu_schedulers_online, dirty_io_schedulers, multi_scheduling, multi_scheduling_blockers, normal_multi_scheduling_blockers, scheduler_bind_type, scheduler_bindings, scheduler_id, schedulers, smp_support, threads, thread_pool_size
Distribution Information — creation, delayed_node_table_gc, dist, dist_buf_busy_limit, dist_ctrl
System Information — c_compiler_used, check_io, debug_compiled, driver_version, dynamic_trace, dynamic_trace_probes, embedded_3pps, emu_flavor, emu_type, info, kernel_poll, loaded, machine, modified_timing_level, nif_version, otp_release, outstanding_system_requests_limit, port_parallelism, system_architecture, system_logger, system_version, trace_control_word, version, wordsize

🧠 Memory Allocation 🧠

Okay bestie, this one spills all the tea about the memory allocators of the current system (aka the emulator) based on what you pass as Item:

allocated_areas — Returns [tuple()] with information about miscellaneous allocated memory areas.

Each tuple contains an atom describing the type of memory as first element and the amount of allocated memory in bytes as second element. When information about allocated and used memory is present, also a third element is present, containing the amount of used memory in bytes.

erlang:system_info(allocated_areas) is intended for debugging, and the content is highly implementation-dependent. The content of the results therefore changes when needed without prior notice.

Notice that the sum of these values is not the total amount of memory allocated by the emulator. Some values are part of other values, and some memory areas are not part of the result. For information about the total amount of memory allocated by the emulator, see erlang:memory/0,1.

allocator — Returns

{Allocator :: undefined | glibc,
 Version :: [non_neg_integer()],
 Features :: [atom()],
 Settings :: [{Subsystem :: atom(),
               [{Parameter :: atom(),
                 Value :: term()}]
               }]
}

where

Allocator corresponds to the malloc() implementation used. If Allocator equals undefined, the malloc() implementation used cannot be identified. glibc can be identified.
Version is a list of integers (but not a string) representing the version of the malloc() implementation used.
Features is a list of atoms representing the allocation features used.
Settings is a list of subsystems, their configurable parameters, and used values. Settings can differ between different combinations of platforms, allocators, and allocation features. Memory sizes are given in bytes.

See also "System Flags Effecting erts_alloc" in erts_alloc(3).

{allocator, Alloc} — Returns information about the specified allocator. As from ERTS 5.6.1, the return value is a list of {instance, InstanceNo, InstanceInfo} tuples, where InstanceInfo contains information about a specific instance of the allocator. If Alloc is not a recognized allocator, undefined is returned. If Alloc is disabled, false is returned.

Notice that the information returned is highly implementation-dependent and can be changed or removed at any time without prior notice. It was initially intended as a tool when developing new allocators, but as it can be of interest for others it has been briefly documented.

The recognized allocators are listed in erts_alloc(3). Information about super carriers can be obtained from ERTS 8.0 with {allocator, erts_mmap} or from ERTS 5.10.4; the returned list when calling with {allocator, mseg_alloc} also includes an {erts_mmap, _} tuple as one element in the list.

After reading the erts_alloc(3) documentation, the returned information more or less speaks for itself, but it can be worth explaining some things. Call counts are presented by two values, the first value is giga calls, and the second value is calls. mbcs and sbcs denote multi-block carriers, and single-block carriers, respectively. Sizes are presented in bytes. When a size is not presented, it is the amount of something. Sizes and amounts are often presented by three values:

The first is the current value.
The second is the maximum value since the last call to erlang:system_info({allocator, Alloc}).
The third is the maximum value since the emulator was started.

If only one value is present, it is the current value. fix_alloc memory block types are presented by two values. The first value is the memory pool size and the second value is the used memory size.

alloc_util_allocators — Returns a list of the names of all allocators using the ERTS internal alloc_util framework as atoms. For more information, see section The alloc_util framework in erts_alloc(3).
{allocator_sizes, Alloc} — Returns various size information for the specified allocator. The information returned is a subset of the information returned by erlang:system_info({allocator, Alloc}).

🖥️ CPU Topology 🖥️

Returns various information about the CPU topology of the current system (emulator) as specified by Item:

cpu_topology — Returns the cpu_topology() currently used by the emulator. The CPU topology is used when binding schedulers to logical processors. The CPU topology used is the user-defined CPU topology, if such exists, otherwise the automatically detected CPU topology, if such exists. If no CPU topology exists, undefined is returned.
{cpu_topology, defined} — Returns the user-defined cpu_topology(). For more information, see command-line flag +sct in erl(1) and argument cpu_topology.
{cpu_topology, detected} — Returns the automatically detected cpu_topology(). The emulator detects the CPU topology on some newer Linux, Solaris, FreeBSD, and Windows systems. On Windows system with more than 32 logical processors, the CPU topology is not detected.

For more information, see argument cpu_topology.

{cpu_topology, used} — Returns CpuTopology used by the emulator. For more information, see argument cpu_topology.
logical_processors — Returns the detected number of logical processors configured in the system. The return value is either an integer, or the atom unknown if the emulator cannot detect the configured logical processors.
logical_processors_available — Returns the detected number of logical processors available to the Erlang runtime system. The return value is either an integer, or the atom unknown if the emulator cannot detect the available logical processors. The number of available logical processors is less than or equal to the number of logical processors online.
logical_processors_online — Returns the detected number of logical processors online on the system. The return value is either an integer, or the atom unknown if the emulator cannot detect logical processors online. The number of logical processors online is less than or equal to the number of logical processors configured.
cpu_quota — Returns the detected CPU quota the emulator is limited by. The return value is an integer saying how many processors' worth of runtime we get (between 1 and the number of logical processors), or the atom unknown if the emulator cannot detect a quota.
update_cpu_info — The runtime system rereads the CPU information available and updates its internally stored information about the detected CPU topology and the number of logical processors configured, online, available, and cpu quota.

If the CPU information has changed since the last time it was read, the atom changed is returned, otherwise the atom unchanged. If the CPU information has changed, you probably want to adjust the number of schedulers online. You typically want to have as many schedulers online as logical processors available.

Since: OTP R14B

🧵 Process Information 🧵

Returns information about the default process heap settings:

fullsweep_after — Returns {fullsweep_after, integer() >= 0}, which is the fullsweep_after garbage collection setting used by default. For more information, see garbage_collection described below.
garbage_collection — Returns garbage_collection_defaults/0 describing the default garbage collection settings. A process spawned on the local node by a spawn or spawn_link uses these garbage collection settings. The default settings can be changed by using erlang:system_flag/2. spawn_opt/2,3,4 can spawn a process that does not use the default settings.
heap_sizes — Returns a list of integers representing valid heap sizes in words. All Erlang heaps are sized from sizes in this list.
heap_type — Returns the heap type used by the current emulator. One heap type exists:
- private — Each process has a heap reserved for its use and no references between heaps of different processes are allowed. Messages passed between processes are copied between heaps.
max_heap_size — Returns {max_heap_size, MaxHeapSize}, where MaxHeapSize is the current system-wide maximum heap size settings for spawned processes. This setting can be set using the command-line flags +hmax, +hmaxk, +hmaxel and +hmaxibl in erl(1). It can also be changed at runtime using erlang:system_flag(max_heap_size, MaxHeapSize). For more details about the max_heap_size process flag, see process_flag(max_heap_size, MaxHeapSize).

Since: OTP 19.0

`message_queue_data`

Gives you the default value of the message_queue_data process flag, bestie — and it's one of two things: off_heap or on_heap. That default gets set by the command-line argument +hmqd over in erl(1). Want the full tea on what those values actually mean? Go read the docs for process_flag(message_queue_data, MQD).

Since: OTP 19.0

`min_heap_size`

Returns {min_heap_size, MinHeapSize}, where MinHeapSize is the right-now, system-wide minimum heap size that freshly spawned processes get. ✨

Since: OTP R13B04

`min_bin_vheap_size`

Returns {min_bin_vheap_size, MinBinVHeapSize}, and MinBinVHeapSize is the current system-wide minimum binary virtual heap size handed to newly spawned processes. 🎀

Since: OTP R13B04

`procs`

Returns a binary — yes, a whole binary — holding a string of process AND port info, formatted exactly like it is in Erlang crash dumps. For the full how-to-read-it situation, check the section How to interpret the Erlang crash dumps in the User's Guide. 💅

✨ System Limits ✨

Hands you info about the current system (emulator) limits, depending on what Item you ask for:

`atom_count`

Returns the number of atoms that currently exist at the local node, as an integer. 🔢

Since: OTP 20.0

`atom_limit`

Returns the maximum number of atoms allowed. You can bump this limit at startup by passing command-line flag +t to erl(1). 👑

Since: OTP 20.0

`ets_count`

Returns the number of ETS tables currently existing at the local node.

Since: OTP 21.1

`ets_limit`

Returns the limit for the number of ETS tables. Ngl, this limit is partially obsolete — the number of tables is really only limited by available memory. 💀

Since: OTP R16B03

`port_count`

Returns the number of ports currently existing at the local node, as an integer. This is literally the same value length(erlang:ports()) gives you — it's just way more efficient. 🚀

Since: OTP R16B

`port_limit`

Returns the maximum number of simultaneously existing ports at the local node, as an integer. You can configure this limit at startup with command-line flag +Q in erl(1).

Since OTP R16B

`process_count`

Returns the number of processes currently existing at the local node, as an integer. Same value as length(processes()) returns — but, again, more efficient, no cap. 💯

`process_limit`

Returns the maximum number of simultaneously existing processes at the local node, as an integer. You can set this limit at startup with command-line flag +P in erl(1).

🕰️ System Time 🕰️

Gives you info about the current system (emulator) time, based on what Item you ask for:

`end_time`

The last Erlang monotonic time — in native time unit — that can even be represented internally in the current Erlang runtime system instance. Fun fact: the gap between the start time and the end time is at least a quarter of a millennium. Iconic longevity fr fr. ⏳

Since: OTP 18.0

`os_monotonic_time_source`

Returns a list with info about the source of OS monotonic time that the runtime system is using.

If [] comes back, that means no OS monotonic time is available at all. The list holds two-tuples where the first element is a Key and the second is a Value. The order of these tuples is undefined, so don't you dare rely on it. 🙈 These tuples can be part of the list — and, heads up, more tuples can be introduced in the future:

{function, Function} — Function is the name of the function being used. This tuple always exists if OS monotonic time is available to the runtime system.
{clock_id, ClockId} — This tuple only exists if Function can be used with different clocks. ClockId corresponds to the clock identifier used when calling Function.
{resolution, OsMonotonicTimeResolution} — The highest possible resolution of the current OS monotonic time source, in parts per second. If no resolution info can be pulled from the OS, OsMonotonicTimeResolution is set to the resolution of the time unit of Functions return value. So the actual resolution can be lower than OsMonotonicTimeResolution. Notice: resolution says nothing about accuracy, and nothing about whether the precision aligns with the resolution. What you DO know is that the precision isn't better than OsMonotonicTimeResolution.
{used_resolution, UsedOsMonotonicTimeResolution} — The OS monotonic time resolution the runtime system is actually using. Very often this equals OsMonotonicTimeResolution. But on some systems the resolution has to be reduced to reliably produce monotonic timestamps. A prime example: when QueryPerformanceCounter() is used as the OS monotonic time source on Windows. If a reduction like that happened, UsedOsMonotonicTimeResolution will be smaller than OsMonotonicTimeResolution.
{extended, Extended} — Extended equals yes if the range of time values has been extended; otherwise Extended equals no. The range must be extended if Function returns values that wrap fast — which is typically the case when the return value is a 32-bit value.
{parallel, Parallel} — Parallel equals yes if Function is called in parallel from multiple threads. If it's not called in parallel, because calls must be serialized, Parallel equals no.
{time, OsMonotonicTime} — OsMonotonicTime equals the current OS monotonic time in native time unit.

Since: OTP 18.0

`os_system_time_source`

Returns a list with info about the source of OS system time that the runtime system is using.

The list contains two-tuples where the first element is a Key and the second is a Value. The order of these tuples is undefined. These tuples can be part of the list — and more tuples can be introduced in the future:

{function, Function} — Function is the name of the function being used.
{clock_id, ClockId} — Exists only if Function can be used with different clocks. ClockId corresponds to the clock identifier used when calling Function.
{resolution, OsSystemTimeResolution} — Highest possible resolution of the current OS system time source, in parts per second. If no resolution info can be retrieved from the OS, OsSystemTimeResolution is set to the resolution of the time unit of Functions return value. So the actual resolution can be lower than OsSystemTimeResolution. Notice that resolution says nothing about accuracy or whether the precision does align with the resolution. You do, however, know that the precision isn't better than OsSystemTimeResolution.
{parallel, Parallel} — Parallel equals yes if Function is called in parallel from multiple threads. If it isn't called in parallel, because calls need to be serialized, Parallel equals no.
{time, OsSystemTime} — OsSystemTime equals the current OS system time in native time unit.

Since: OTP 18.0

`start_time`

The Erlang monotonic time — in native time unit — at the moment the current Erlang runtime system instance started. 🌱

See also erlang:system_info(end_time).

Since: OTP 18.0

`time_correction`

Returns a boolean() value telling you whether time correction is enabled or not. ✅❌

Since: OTP 18.0

`time_offset`

Returns the state of the time offset:

preliminary — The time offset is preliminary and will be changed and finalized later. The preliminary time offset is used during the preliminary phase of the single time warp mode.
final — The time offset is final. Either because no time warp mode is used, or because the time offset has been finalized when single time warp mode is used.
volatile — The time offset is volatile. That is, it can change at any time. This is because multi-time warp mode is used.

Since: OTP 18.0

`time_warp_mode`

Returns a value identifying which time warp mode is in play:

no_time_warp — The no time warp mode is used.
single_time_warp — The single time warp mode is used.
multi_time_warp — The multi-time warp mode is used.

Since: OTP 18.0

`tolerant_timeofday`

Returns whether a pre ERTS 7.0 backwards compatible compensation for sudden changes of system time is enabled or disabled. That compensation is enabled when the time offset is final and time correction is enabled. 🫶

Since: OTP 17.1

🧚 Scheduler Information 🧚

Gives you info about schedulers, scheduling, and threads in the current system, based on what Item you ask for:

`dirty_cpu_schedulers`

Returns the number of dirty CPU scheduler threads the emulator is using. Dirty CPU schedulers run CPU-bound native functions — think NIFs, linked-in driver code, and BIFs that the normal emulator schedulers just can't manage cleanly.

The number of dirty CPU scheduler threads is set at emulator boot time and cannot be changed after that. However — plot twist — the number of dirty CPU schedulers online can be changed at any time. You can set the number of dirty CPU schedulers at startup by passing command-line flag +SDcpu or +SDPcpu in erl(1). 🔥

See also erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline), erlang:system_info(dirty_cpu_schedulers_online), erlang:system_info(dirty_io_schedulers), erlang:system_info(schedulers), erlang:system_info(schedulers_online), and erlang:system_flag(schedulers_online, SchedulersOnline).

Since: OTP 17.0

`dirty_cpu_schedulers_online`

Returns the number of dirty CPU schedulers online. The return value satisfies 1 <= DirtyCPUSchedulersOnline <= N, where N is the smallest of the return values of erlang:system_info(dirty_cpu_schedulers) and erlang:system_info(schedulers_online).

You can set the number of dirty CPU schedulers online at startup by passing command-line flag +SDcpu in erl(1). ✨

For more info, see erlang:system_info(dirty_cpu_schedulers), erlang:system_info(dirty_io_schedulers), erlang:system_info(schedulers_online), and erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline).

Since: OTP 17.0

`dirty_io_schedulers`

Returns the number of dirty I/O schedulers, as an integer. Dirty I/O schedulers run I/O-bound native functions — like NIFs and linked-in driver code — which the normal emulator schedulers can't manage cleanly. 🌈

You can set this value at startup by passing command-line argument +SDio in erl(1).

For more info, see erlang:system_info(dirty_cpu_schedulers), erlang:system_info(dirty_cpu_schedulers_online), and erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline).

Since: OTP 17.0

multi_scheduling — hands you back one of these four vibes:
- disabled — the emulator got started with literally one scheduler thread and that's the whole roster.
- blocked — there's more than one scheduler thread, but every single one except one is blocked. So like, only one scheduler thread is out here scheduling Erlang processes and executing Erlang code. One. Alone. 😭
- blocked_normal — more than one scheduler thread exists, but all the normal scheduler threads except one are blocked. Important tea though: dirty schedulers are not blocked, and they can still schedule Erlang processes and execute native code. So it's not a total shutdown, bestie.
- enabled — more than one scheduler thread and nothing is blocked. All available scheduler threads are scheduling Erlang processes and executing Erlang code. Full squad, all present. 👑

See also erlang:system_flag(multi_scheduling, BlockState), erlang:system_info(multi_scheduling_blockers), erlang:system_info(normal_multi_scheduling_blockers), and erlang:system_info(schedulers).

multi_scheduling_blockers — returns a list of Pids when multi-scheduling is blocked, and otherwise you just get the empty list back. Those Pids in the list are every process currently blocking multi-scheduling. And a Pid shows up only once in the list, even if that process has blocked multiple times — no duplicates, we respect the count. ✨

See also erlang:system_flag(multi_scheduling, BlockState), erlang:system_info(multi_scheduling), erlang:system_info(normal_multi_scheduling_blockers), and erlang:system_info(schedulers).

normal_multi_scheduling_blockers — returns a list of Pids when normal multi-scheduling is blocked (that is, all normal schedulers but one are blocked), and otherwise the empty list. Those Pids are all the processes currently blocking normal multi-scheduling. Same rule as before: a Pid occurs only once in the list even if it blocked multiple times. 🫶

See also erlang:system_flag(multi_scheduling, BlockState), erlang:system_info(multi_scheduling), erlang:system_info(multi_scheduling_blockers), and erlang:system_info(schedulers).

Since: OTP 19.0

scheduler_bind_type — returns scheduler_bind_type(), which is the tea on how the user has requested schedulers to be bound or not bound.

Real talk though: even if a user requested that schedulers be bound, they could have silently just… failed to bind. No error, no drama, just vibes. To actually inspect the scheduler bindings, call erlang:system_info(scheduler_bindings).

For more info, see command-line argument +sbt in erl(1) and erlang:system_info(scheduler_bindings).

scheduler_bindings — tells you about the scheduler bindings currently in use.

You get a tuple whose size equals erlang:system_info(schedulers). The tuple elements are integers or the atom unbound. Logical processor identifiers show up as integers. The Nth element of the tuple is the current binding for the scheduler whose scheduler identifier equals N. So for example, if the schedulers are bound, element(erlang:system_info(scheduler_id), erlang:system_info(scheduler_bindings)) returns the identifier of the logical processor that the calling process is executing on. Cute, right? 💅

Heads up: only schedulers online can be bound to logical processors.

For more info, see command-line argument +sbt in erl(1) and erlang:system_info(schedulers_online).

scheduler_id — returns the scheduler ID (SchedulerId) of the scheduler thread that the calling process is executing on. SchedulerId is a positive integer where 1 <= SchedulerId <= erlang:system_info(schedulers).

See also erlang:system_info(schedulers).

schedulers — returns the number of scheduler threads the emulator is using. Scheduler threads online schedule Erlang processes and Erlang ports, and execute Erlang code and Erlang linked-in driver code. Iconic multitasking fr.

The number of scheduler threads is decided at emulator boot time and cannot be changed later. Locked in, periodt. But the number of schedulers online can be changed at any time — that one's flexible.

See also erlang:system_flag(schedulers_online, SchedulersOnline), erlang:system_info(schedulers_online), erlang:system_info(scheduler_id), erlang:system_flag(multi_scheduling, BlockState), erlang:system_info(multi_scheduling), erlang:system_info(normal_multi_scheduling_blockers) and erlang:system_info(multi_scheduling_blockers).

schedulers_online — returns the number of schedulers online. The scheduler identifiers of the schedulers online satisfy 1 <= SchedulerId <= erlang:system_info(schedulers_online).

For more info, see erlang:system_info(schedulers) and erlang:system_flag(schedulers_online, SchedulersOnline).

smp_support — returns true. That's the whole thing. Slay. ✨
threads — returns true. Also the whole thing. 💖
thread_pool_size — returns the number of async threads in the async thread pool used for asynchronous driver calls (erl_driver:driver_async()). The value is given as an integer.

🌈 Distribution Information 🌈

Returns the tea about Erlang Distribution in the current system, as specified by Item:

async_dist — returns the value of the command line argument +pad <boolean> that the runtime system uses. This value determines the default async_dist value for newly spawned processes.

Since: OTP 25.3

creation — returns the "creation" value of the local node as an integer. The creation changes whenever a node is restarted. The creation of a node is stored in process identifiers, port identifiers, and references. This is what makes it possible to tell apart identifiers from different incarnations of a node — same node name, different era, iykyk. Creation values are currently 32-bit positive integers, but this may change in future releases. If the node is not alive, 0 is returned.
delayed_node_table_gc — returns the amount of time in seconds that garbage collection of an entry in a node table is delayed. This limit can be set on startup by passing command-line flag +zdntgc to erl(1). For more info, see the documentation of that command-line flag.

Since: OTP 18.0

dist — returns a binary containing a string of distribution information, formatted the same way as in Erlang crash dumps. For more info, see the section How to interpret the Erlang crash dumps in the User's Guide.
dist_buf_busy_limit — returns the value of the distribution buffer busy limit in bytes. This limit can be set at startup by passing command-line flag +zdbbl to erl(1).

Since: OTP R14B01

dist_ctrl — returns a list of tuples {Node :: node(), ControllingEntity :: port() | pid()}, with one entry for each connected remote node. Node is the node name, and ControllingEntity is the port or process identifier responsible for the communication with that node. More specifically, ControllingEntity for nodes connected through TCP/IP (the normal case) is the socket used in communication with that specific node.

🦋 System Information 🦋

Returns various information about the current system (the emulator), as specified by Item:

c_compiler_used — returns a two-tuple describing the C compiler used when compiling the runtime system. The first element is an atom describing the name of the compiler, or undefined if that's unknown. The second element is a term describing the version of the compiler, or undefined if that's unknown.
check_io — returns a list containing miscellaneous information about the emulator's internal I/O checking. Just so you know: the contents of that returned list can vary between platforms and over time. The only guarantee is that a list comes back. That's it, that's the promise. 🙈
debug_compiled — returns true if the emulator has been debug-compiled, otherwise false.
driver_version — returns a string containing the Erlang driver version used by the runtime system. The form is "<major ver>.<minor ver>".
dynamic_trace — returns an atom describing the dynamic trace framework compiled into the virtual machine. It can be dtrace, systemtap, or none. For a commercial or standard build it is always none. The other return values mean a custom configuration (for example, ./configure --with-dynamic-trace=dtrace). For more info about dynamic tracing, see the dyntrace(3) manual page and the README.dtrace/README.systemtap files in the Erlang source code top directory.

Since: OTP R15B01

dynamic_trace_probes — returns a boolean() indicating whether dynamic trace probes (dtrace or systemtap) are built into the emulator. This can only be true if the virtual machine was built for dynamic tracing (that is, system_info(dynamic_trace) returns dtrace or systemtap).

Since: OTP R15B01

embedded_3pps — returns a map with info about third party products embedded in the source code of the Erlang/OTP runtime system. Note that often only parts (and in some cases minuscule parts) of these third party products have been embedded in the source code. Currently the returned map contains these keys:
- included — the value of this key is a list of atoms, where each atom represents a third party product from which code has been embedded in the source code and has also been included into the built runtime system.
- excluded — the value of this key is a list of atoms, where each atom represents a third party product from which code has been embedded in the source code, but which has been completely excluded in the built runtime system. That exclusion might be because the functionality is disabled, because the functionality is implemented using other primitives on that specific system, or because the runtime system is linked against the same or another third party product installed on the system.

Note that the returned map may be extended with new key/value pairs at any time. No cap on the glow-up. ✨

Since: OTP 28.5

emu_flavor — returns an atom describing the flavor of the runtime system. This will be either emu or jit. Possible return values can be added or removed at any time without prior notice.

Since: OTP 24.0

emu_type — returns an atom describing the build type of the runtime system. Normally this is the atom opt for optimized. Other possible return values are debug, gcov, valgrind, gprof, and lcnt. Possible return values can be added or removed at any time without prior notice.

Since: OTP 24.0

halt_flush_timeout — returns the default halt flush timeout set by the erl +zhft <Timeout> command line flag.

Since: OTP 27.0

info — drops a binary with a string of miscellaneous system info, formatted exactly like it shows up in Erlang crash dumps 📋. Wanna actually decode it? Go read the section How to interpret the Erlang crash dumps in the User's Guide, bestie.
kernel_poll — returns true if the emulator is out here using some kind of kernel-poll implementation, otherwise false 💅.
loaded — hands you a binary with a string of loaded module info, formatted just like in Erlang crash dumps 📦. More deets? See How to interpret the Erlang crash dumps in the User's Guide.
machine — returns a string with the Erlang machine name 🏷️.
modified_timing_level — returns the modified timing-level (an integer()) if modified timing is on, otherwise undefined ⏱️. Curious about modified timing? Check command-line flag +T in erl(1).
nif_version — returns a string with the version of the Erlang NIF interface that the runtime system is running 🧩. It's formatted like "<major ver>.<minor ver>".

Since: OTP 17.4

otp_release — returns a string with the OTP release number of the OTP release that the currently executing ERTS application is part of 👑.

As from Erlang/OTP 17, the OTP release number lines up with the major OTP version number. Fr fr, no erlang:system_info() argument gives you the exact OTP version — and that's because nailing down the exact OTP version is genuinely hard in the general case 😭. For the whole story, see the description of versions in System principles in System Documentation.

outstanding_system_requests_limit — returns the limit on how many outstanding requests a system process orchestrating system-wide changes can have going at once 🚦. See erlang:system_flag(outstanding_system_requests_limit, Limit) for more.

Since: OTP 24.2

port_parallelism — returns the default port parallelism scheduling hint in use 🌸. For more, see command-line argument +spp in erl(1).

Since: OTP R16B

system_architecture — returns a string with the processor and OS architecture that the emulator was built for 🏗️.
system_logger — returns the current system_logger, as set by erlang:system_flag(system_logger, *) 📝.

Since: OTP 21.3

system_version — returns a string with the version number plus some important properties, like the number of schedulers ⭐.
trace_control_word — returns the value of the node trace control word 🔍. For more, see function get_tcw in the section Match Specifications in Erlang in the User's Guide.
version — returns a string with the version number of the emulator 🎀.
wordsize — same as {wordsize, internal} .
{wordsize, internal} — returns the size of Erlang term words in bytes, as an integer 🧮. So: 4 comes back on a 32-bit architecture, and 8 comes back on a 64-bit architecture.
{wordsize, external} — returns the true word size of the emulator, aka the size of a pointer 👉. The value comes in bytes as an integer. On a pure 32-bit architecture you get 4. On a 64-bit architecture you get 8.

And that's the whole page, bestie, we ate that 💅✨ no cap. This lil masterpiece is from Ericsson AB, it's erts version 17.0.6, and it lives at page erlang_system_info(3) — go forth and query your system info responsibly 🫶🌸

📦 where this page comes from

ubuntu stonking: erlang-doc 1:29.0.6+dfsg-1 · Apache-2.0
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-11-03: a language model's rewrite of the original, under its terms