erlang_system_info(3)

NAME
erlang_system_info - 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, 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

Returns various information about the memory allocators of the current system (emulator) as specified by 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
    Returns the default value of the message_queue_data process flag, which can be either off_heap or on_heap. The default value is set by the command-line argument +hmqd in erl(1). For more information, see the documentation of process_flag(message_queue_data, MQD).

    Since: OTP 19.0
min_heap_size
    Returns {min_heap_size, MinHeapSize}, where MinHeapSize is the current system-wide minimum heap size for spawned processes.

    Since: OTP R13B04
min_bin_vheap_size
    Returns {min_bin_vheap_size, MinBinVHeapSize}, where MinBinVHeapSize is the current system-wide minimum binary virtual heap size for spawned processes.

    Since: OTP R13B04
procs
    Returns a binary containing a string of process and port information formatted as in Erlang crash dumps. For more information, see section How to interpret the Erlang crash dumps in the User's Guide.

  System Limits

Returns information about the current system (emulator) limits as specified by Item: atom_count
    Returns the number of atoms currently existing at the local node. The value is given as an integer.

    Since: OTP 20.0
atom_limit
    Returns the maximum number of atoms allowed. This limit can be increased 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 number of ETS tables. This limit is partially obsolete and number of tables are only limited by available memory.

    Since: OTP R16B03
port_count
    Returns the number of ports currently existing at the local node. The value is given as an integer. This is the same value as returned by length(erlang:ports()), but more efficient.

    Since: OTP R16B
port_limit
    Returns the maximum number of simultaneously existing ports at the local node as an integer. This limit can be configured at startup by using command-line flag +Q in erl(1).

    Since OTP R16B
process_count
    Returns the number of processes currently existing at the local node. The value is given as an integer. This is the same value as returned by length(processes()), but more efficient.
process_limit
    Returns the maximum number of simultaneously existing processes at the local node. The value is given as an integer. This limit can be configured at startup by using command-line flag +P in erl(1).

  System Time

Returns information about the current system (emulator) time as specified by Item: end_time
    The last Erlang monotonic time in native time unit that can be represented internally in the current Erlang runtime system instance. The time between the start time and the end time is at least a quarter of a millennium.

    Since: OTP 18.0
os_monotonic_time_source
    Returns a list containing information about the source of OS monotonic time that is used by the runtime system.

    If [] is returned, no OS monotonic time is available. The list contains two-tuples with Keys as first element, and Values as second element. The order of these tuples is undefined. The following tuples can be part of the list, but more tuples can be introduced in the future: {function, Function}
        Function is the name of the function 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}
        Highest possible resolution of current OS monotonic time source as parts per second. If no resolution information can be retrieved from the OS, OsMonotonicTimeResolution is set to the resolution of the time unit of Functions return value. That is, the actual resolution can be lower than OsMonotonicTimeResolution. Notice that the resolution does not say anything about the accuracy or whether the precision aligns with the resolution. You do, however, know that the precision is not better than OsMonotonicTimeResolution.
    {used_resolution, UsedOsMonotonicTimeResolution}
        The OS monotonic time resolution used by the runtime system. This is very often the same as OsMonotonicTimeResolution. However, on some systems the resolution has to be reduced in order to reliably produce monotonic timestamps. An example of this is when QueryPerformanceCounter() is used as OS monotonic time source on Windows. If such a reduction of the resolution has been done, 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. This typically is 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 is not called in parallel, because calls must be serialized, Parallel equals no.
    {time, OsMonotonicTime}
        OsMonotonicTime equals current OS monotonic time in native time unit.

    Since: OTP 18.0
os_system_time_source
    Returns a list containing information about the source of OS system time that is used by the runtime system.

    The list contains two-tuples with Keys as first element, and Values as second element. The order of these tuples is undefined. The following tuples can be part of the list, but more tuples can be introduced in the future: {function, Function}
        Function is the name of the function 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 current OS system time source as parts per second. If no resolution information can be retrieved from the OS, OsSystemTimeResolution is set to the resolution of the time unit of Functions return value. That is, the actual resolution can be lower than OsSystemTimeResolution. Notice that the resolution does not say anything about the accuracy or whether the precision do align with the resolution. You do, however, know that the precision is not better than OsSystemTimeResolution.
    {parallel, Parallel}
        Parallel equals yes if Function is called in parallel from multiple threads. If it is not called in parallel, because calls needs to be serialized, Parallel equals no.
    {time, OsSystemTime}
        OsSystemTime equals current OS system time in native time unit.

    Since: OTP 18.0
start_time
    The Erlang monotonic time in native time unit at the time when current Erlang runtime system instance started.

    See also erlang:system_info(end_time).

    Since: OTP 18.0
time_correction
    Returns a boolean() value indicating 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. This either because no time warp mode is used, or because the time offset have 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 the time warp mode that is used: 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. Such compensation is enabled when the time offset is final, and time correction is enabled.

    Since: OTP 17.1

  Scheduler Information

Returns information about schedulers, scheduling and threads in the current system as specified by Item: dirty_cpu_schedulers
    Returns the number of dirty CPU scheduler threads used by the emulator. Dirty CPU schedulers execute CPU-bound native functions, such as NIFs, linked-in driver code, and BIFs that cannot be managed cleanly by the normal emulator schedulers.

    The number of dirty CPU scheduler threads is determined at emulator boot time and cannot be changed after that. However, the number of dirty CPU scheduler threads online can be changed at any time. The number of dirty CPU schedulers can be set 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).

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

    For more information, 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 execute I/O-bound native functions, such as NIFs and linked-in driver code, which cannot be managed cleanly by the normal emulator schedulers.

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

    For more information, 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
    Returns one of the following: disabled
        The emulator has been started with only one scheduler thread.
    blocked
        The emulator has more than one scheduler thread, but all scheduler threads except one are blocked. That is, only one scheduler thread schedules Erlang processes and executes Erlang code.
    blocked_normal
        The emulator has more than one scheduler thread, but all normal scheduler threads except one are blocked. Notice that dirty schedulers are not blocked, and can schedule Erlang processes and execute native code.
    enabled
        The emulator has more than one scheduler thread, and no scheduler threads are blocked. That is, all available scheduler threads schedule Erlang processes and execute Erlang code.

    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, otherwise the empty list is returned. The Pids in the list represent all the processes currently blocking multi-scheduling. A Pid occurs only once in the list, even if the corresponding process has blocked multiple times.

    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 is blocked), otherwise the empty list is returned. The Pids in the list represent all the processes currently blocking normal multi-scheduling. A Pid occurs only once in the list, even if the corresponding process has 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(), information about how the user has requested schedulers to be bound or not bound.

    Notice that although a user has requested schedulers to be bound, they can silently have failed to bind. To inspect the scheduler bindings, call erlang:system_info(scheduler_bindings).

    For more information, see command-line argument +sbt in erl(1) and erlang:system_info(scheduler_bindings).
scheduler_bindings
    Returns information about the currently used scheduler bindings.

    A tuple of a size equal to erlang:system_info(schedulers) is returned. The tuple elements are integers or the atom unbound. Logical processor identifiers are represented as integers. The Nth element of the tuple equals the current binding for the scheduler with the scheduler identifier equal to N. 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.

    Notice that only schedulers online can be bound to logical processors.

    For more information, 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 used by the emulator. Scheduler threads online schedules Erlang processes and Erlang ports, and execute Erlang code and Erlang linked-in driver code.

    The number of scheduler threads is determined at emulator boot time and cannot be changed later. However, the number of schedulers online can be changed at any time.

    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 schedulers online satisfy the relationship 1 <= SchedulerId <= erlang:system_info(schedulers_online).

    For more information, see erlang:system_info(schedulers) and erlang:system_flag(schedulers_online, SchedulersOnline).
smp_support
    Returns true.
threads
    Returns true.
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 information about Erlang Distribution in the current system as specified by Item: async_dist
    Returns the value of the command line argument +pad <boolean> which the runtime system use. 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 is changed when a node is restarted. The creation of a node is stored in process identifiers, port identifiers, and references. This makes it possible to distinguish between identifiers from different incarnations of a node. 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 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 information, see the documentation of the command-line flag.

    Since: OTP 18.0
dist
    Returns a binary containing a string of distribution information formatted as in Erlang crash dumps. For more information, see 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()}, one entry for each connected remote node. Node is the node name and ControllingEntity is the port or process identifier responsible for the communication to that node. More specifically, ControllingEntity for nodes connected through TCP/IP (the normal case) is the socket used in communication with the specific node.

  System Information

Returns various information about the current system (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 unknown. The second element is a term describing the version of the compiler, or undefined if unknown.
check_io
    Returns a list containing miscellaneous information about the emulators internal I/O checking. Notice that the content of the returned list can vary between platforms and over time. It is only guaranteed that a list is returned.
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. It has the form "<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 indicate a custom configuration (for example, ./configure --with-dynamic-trace=dtrace). For more information about dynamic tracing, see 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 if 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
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. This is normally 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
    Returns a binary containing a string of miscellaneous system information formatted as in Erlang crash dumps. For more information, see section How to interpret the Erlang crash dumps in the User's Guide.
kernel_poll
    Returns true if the emulator uses some kind of kernel-poll implementation, otherwise false.
loaded
    Returns a binary containing a string of loaded module information formatted as in Erlang crash dumps. For more information, see section How to interpret the Erlang crash dumps in the User's Guide.
machine
    Returns a string containing the Erlang machine name.
modified_timing_level
    Returns the modified timing-level (an integer()) if modified timing is enabled, otherwise undefined. For more information about modified timing, see command-line flag +T in erl(1)
nif_version
    Returns a string containing the version of the Erlang NIF interface used by the runtime system. It is on the form "<major ver>.<minor ver>".

    Since: OTP 17.4
otp_release
    Returns a string containing 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 corresponds to the major OTP version number. No erlang:system_info() argument gives the exact OTP version. This is because the exact OTP version in the general case is difficult to determine. For more information, see the description of versions in System principles in System Documentation.
outstanding_system_requests_limit
    Returns the limit on the amount of outstanding requests made by a system process orchestrating system wide changes. See erlang:system_flag(outstanding_system_requests_limit, Limit) for more information.

    Since: OTP 24.2
port_parallelism
    Returns the default port parallelism scheduling hint used. For more information, see command-line argument +spp in erl(1).

    Since: OTP R16B
system_architecture
    Returns a string containing the processor and OS architecture the emulator is 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 containing version number and some important properties, such as the number of schedulers.
trace_control_word
    Returns the value of the node trace control word. For more information, see function get_tcw in section Match Specifications in Erlang in the User's Guide.
version
    Returns a string containing 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, that is, 4 is returned on a 32-bit architecture, and 8 is returned on a 64-bit architecture.
{wordsize, external}
    Returns the true word size of the emulator, that is, the size of a pointer. The value is given in bytes as an integer. On a pure 32-bit architecture, 4 is returned. On a 64-bit architecture, 8 is returned.