`
mryufeng
  • 浏览: 982457 次
  • 性别: Icon_minigender_1
  • 来自: 广州
社区版块
存档分类
最新评论

erlang运行期的自省机制

阅读更多
   erlang运行期最值得称道的地方之一就是完备的自省机制,也就是说你可以通过这些信息了解整个系统运行的方方面面,给系统的调试,排错,调优,运营提供非常大的便利。在beam的c实现代码中至少1/4的代码在为这个目标服务,信息非常的到位详细,这和爱立信作为商业公司运营交换机的需求有很大的关系。自省分为2个层面的:提供erts运行期信息的和用户进程相关的信息。包括一下一个基础设施:system_flag, system_info,system_profile,system_monitor,erts_debug,the Erlang crash dumps,trace. 以及在otp的os_mon,snmp.

system_flag主要用来微调erts的性能相关参数。
erlang:system_flag(fullsweep_after, Number)

    Number is a non-negative integer which indicates how many times generational garbages collections can be done without forcing a fullsweep collection. The value applies to new processes; processes already running are not affected.
    In low-memory systems (especially without virtual memory), setting the value to 0 can help to conserve memory.
    An alternative way to set this value is through the (operating system) environment variable ERL_FULLSWEEP_AFTER.
erlang:system_flag(min_heap_size, MinHeapSize)
    Sets the default minimum heap size for processes. The size is given in words. The new min_heap_size only effects processes spawned after the change of min_heap_size has been made. The min_heap_size can be set for individual processes by use of spawn_opt/N or process_flag/2.
erlang:system_flag(multi_scheduling, BlockState)
    BlockState = block | unblock
    If multi-scheduling is enabled, more than one scheduler thread is used by the emulator. Multi-scheduling can be blocked. When multi-scheduling has been blocked, only one scheduler thread will schedule Erlang processes.
    If BlockState =:= block, multi-scheduling will be blocked. If BlockState =:= unblock and no-one else is blocking multi-scheduling and this process has only blocked one time, multi-scheduling will be unblocked. One process can block multi-scheduling multiple times. If a process has blocked multiple times, it has to unblock exactly as many times as it has blocked before it has released its multi-scheduling block. If a process that has blocked multi-scheduling exits, it will release its blocking of multi-scheduling.
    The return values are disabled, blocked, or enabled. The returned value describes the state just after the call to erlang:system_flag(multi_scheduling, BlockState) has been made. The return values are described in the documentation of erlang:system_info(multi_scheduling).
    NOTE: Blocking of multi-scheduling should normally not be needed. If you feel that you need to block multi-scheduling, think through the problem at least a couple of times again. Blocking multi-scheduling should only be used as a last resort since it will most likely be a very inefficient way to solve the problem.
    See also erlang:system_info(multi_scheduling), erlang:system_info(multi_scheduling_blockers), and erlang:system_info(schedulers).
erlang:system_flag(trace_control_word, TCW)
    Sets the value of the node's trace control word to TCW. TCW should be an unsigned integer. For more information see documentation of the set_tcw function in the match specification documentation in the ERTS User's Guide.


system_info提供erts最基本的环境信息
erlang:system_info(Type) -> Res

Types:

Type, Res -- see below

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

allocated_areas
    Returns a list of tuples with information about miscellaneous allocated memory areas.
    Each tuple contains an atom describing type of memory as first element and amount of allocated memory in bytes as second element. In those cases when there is information present about allocated and used memory, a third element is present. This third element contains 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 will therefore change when needed without prior notice.
    Note: 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. If you are interested in the total amount of memory allocated by the emulator see erlang:memory/0,1.
allocator
    Returns {Allocator, Version, Features, Settings}.
    Types:

        * Allocator = undefined | elib_malloc | glibc
        * Version = [int()]
        * Features = [atom()]
        * Settings = [{Subsystem, [{Parameter, Value}]}]
        * Subsystem = atom()
        * Parameter = atom()
        * Value = term()

    Explanation:

        * Allocator corresponds to the malloc() implementation used. If Allocator equals undefined, the malloc() implementation used could not be identified. Currently elib_malloc and 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 allocation features used.
        * Settings is a list of subsystems, their configurable parameters, and used values. Settings may 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).
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 the "the alloc_util framework" section in the erts_alloc(3) documentation.
{allocator, Alloc}
    Returns information about the specified allocator. As of erts version 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.
    Note: The information returned is highly implementation dependent and may be changed, or removed at any time without prior notice. It was initially intended as a tool when developing new allocators, but since it might be of interest for others it has been briefly documented.
    The recognized allocators are listed in erts_alloc(3). After reading the erts_alloc(3) documentation, the returned information should more or less speak 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 are abbreviations for, respectively, multi-block carriers, and single-block carriers. Sizes are presented in bytes. When it is not a size that is presented, it is the amount of something. Sizes and amounts are often presented by three values, the first is current value, the second is maximum value since the last call to erlang:system_info({allocator, Alloc}), and the third is 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 memory pool size and the second value used memory size.
{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}).
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 regarding the emulators internal I/O checking. Note, the content of the returned list may vary between platforms and over time. The only thing guaranteed is that a list is returned.
compat_rel
    Returns the compatibility mode of the local node as an integer. The integer returned represents the Erlang/OTP release which the current emulator has been set to be backward compatible with. The compatibility mode can be configured at startup by using the command line flag +R, see erl(1).
creation
    Returns the creation 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 (to some extent) possible to distinguish between identifiers from different incarnations of a node. Currently valid creations are integers in the range 1..3, but this may (probably will) change in the future. If the node is not alive, 0 is returned.
debug_compiled
    Returns true if the emulator has been debug compiled; otherwise, false.
dist
    Returns a binary containing a string of distribution information formatted as in Erlang crash dumps. For more information see the "How to interpret the Erlang crash dumps" chapter in the ERTS User's Guide.
dist_ctrl
    Returns a list of tuples {Node, ControllingEntity}, one entry for each connected remote node. The Node is the name of the node and the ControllingEntity is the port or pid responsible for the communication to that node. More specifically, the ControllingEntity for nodes connected via TCP/IP (the normal case) is the socket actually used in communication with the specific node.
driver_version
    Returns a string containing the erlang driver version used by the runtime system. It will be on the form "<major ver>.<minor ver>".
elib_malloc
    If the emulator uses the elib_malloc memory allocator, a list of two-element tuples containing status information is returned; otherwise, false is returned. The list currently contains the following two-element tuples (all sizes are presented in bytes):

    {heap_size, Size}
        Where Size is the current heap size.
    {max_alloced_size, Size}
        Where Size is the maximum amount of memory allocated on the heap since the emulator started.
    {alloced_size, Size}
        Where Size is the current amount of memory allocated on the heap.
    {free_size, Size}
        Where Size is the current amount of free memory on the heap.
    {no_alloced_blocks, No}
        Where No is the current number of allocated blocks on the heap.
    {no_free_blocks, No}
        Where No is the current number of free blocks on the heap.
    {smallest_alloced_block, Size}
        Where Size is the size of the smallest allocated block on the heap.
    {largest_free_block, Size}
        Where Size is the size of the largest free block on the heap.

fullsweep_after
    Returns {fullsweep_after, int()} which is the fullsweep_after garbage collection setting used by default. For more information see garbage_collection described below.
garbage_collection
    Returns a list describing the default garbage collection settings. A process spawned on the local node by a spawn or spawn_link will use these garbage collection settings. The default settings can be changed by use of system_flag/2. spawn_opt/4 can spawn a process that does not use the default settings.
global_heaps_size
    Returns the current size of the shared (global) heap.
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. Currently the following heap types exist:

    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.
    shared
        One heap for use by all processes. Messages passed between processes are passed by reference.
    hybrid
        A hybrid of the private and shared heap types. A shared heap as well as private heaps are used.

info
    Returns a binary containing a string of miscellaneous system information formatted as in Erlang crash dumps. For more information see the "How to interpret the Erlang crash dumps" chapter in the ERTS 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 the "How to interpret the Erlang crash dumps" chapter in the ERTS User's Guide.
logical_processors
    Returns the number of logical processors detected on the system as an integer or the atom unknown if the emulator wasn't able to detect any.
machine
    Returns a string containing the Erlang machine name.
modified_timing_level
    Returns the modified timing level (an integer) if modified timing has been enabled; otherwise, undefined. See the +T command line flag in the documentation of the erl(1) command for more information on modified timing.
multi_scheduling
    Returns disabled, blocked, or enabled. A description of the return values:

    disabled
        The emulator has only one scheduler thread. The emulator does not have SMP support, or have been started with only one scheduler thread.
    blocked
        The emulator has more than one scheduler thread, but all scheduler threads but one have been blocked, i.e., only one scheduler thread will schedule Erlang processes and execute Erlang code.
    enabled
        The emulator has more than one scheduler thread, and no scheduler threads have been blocked, i.e., all available scheduler threads will schedule Erlang processes and execute Erlang code.

    See also erlang:system_flag(multi_scheduling, BlockState), erlang:system_info(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. The PIDs in the list is PIDs of the processes currently blocking multi-scheduling. A PID will only be present 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), and erlang:system_info(schedulers).
otp_release
    Returns a string containing the OTP release number.
process_count
    Returns the number of processes currently existing at the local node as an integer. The same value as length(processes()) returns.
process_limit
    Returns the maximum number of concurrently existing processes at the local node as an integer. This limit can be configured at startup by using the command line flag +P, see erl(1).
procs
    Returns a binary containing a string of process and port information formatted as in Erlang crash dumps. For more information see the "How to interpret the Erlang crash dumps" chapter in the ERTS User's Guide.
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. A scheduler thread 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 after that.
    See also erlang:system_info(scheduler_id), erlang:system_flag(multi_scheduling, BlockState), erlang:system_info(multi_scheduling), and and erlang:system_info(multi_scheduling_blockers).
smp_support
    Returns true if the emulator has been compiled with smp support; otherwise, false.
system_version
    Returns a string containing the emulator type and version as well as some important properties such as the size of the thread pool, etc.
system_architecture
    Returns a string containing the processor and OS architecture the emulator is built for.
threads
    Returns true if the emulator has been compiled with thread support; otherwise, false is returned.
thread_pool_size
    Returns the number of async threads in the async thread pool used for asynchronous driver calls (driver_async()) as an integer.
trace_control_word
    Returns the value of the node's trace control word. For more information see documentation of the function get_tcw in "Match Specifications in Erlang", ERTS User's Guide.
version
    Returns a string containing the version number of the emulator.
wordsize
    Returns the word size in bytes as an integer, i.e. on a 32-bit architecture 4 is returned, and on a 64-bit architecture 8 is returned.

system_monitor主要用来调优.
erlang:system_monitor(MonitorPid, [Option]) -> MonSettings


Types:

MonitorPid = pid()
Option = {long_gc, Time} | {large_heap, Size} | busy_port | busy_dist_port
Time = Size = int()
MonSettings = {OldMonitorPid, [Option]}
OldMonitorPid = pid()

Sets system performance monitoring options. MonitorPid is a local pid that will receive system monitor messages, and the second argument is a list of monitoring options:

{long_gc, Time}
    If a garbage collection in the system takes at least Time wallclock milliseconds, a message {monitor, GcPid, long_gc, Info} is sent to MonitorPid. GcPid is the pid that was garbage collected and Info is a list of two-element tuples describing the result of the garbage collection. One of the tuples is {timeout, GcTime} where GcTime is the actual time for the garbage collection in milliseconds. The other tuples are tagged with heap_size, heap_block_size, stack_size, mbuf_size, old_heap_size, and old_heap_block_size. These tuples are explained in the documentation of the gc_start trace message (see erlang:trace/3). New tuples may be added, and the order of the tuples in the Info list may be changed at any time without prior notice.
{large_heap, Size}
    If a garbage collection in the system results in the allocated size of a heap being at least Size words, a message {monitor, GcPid, large_heap, Info} is sent to MonitorPid. GcPid and Info are the same as for long_gc above, except that the tuple tagged with timeout is not present. Note: As of erts version 5.6 the monitor message is sent if the sum of the sizes of all memory blocks allocated for all heap generations is equal to or larger than Size. Previously the monitor message was sent if the memory block allocated for the youngest generation was equal to or larger than Size.
busy_port
    If a process in the system gets suspended because it sends to a busy port, a message {monitor, SusPid, busy_port, Port} is sent to MonitorPid. SusPid is the pid that got suspended when sending to Port.
busy_dist_port
    If a process in the system gets suspended because it sends to a process on a remote node whose inter-node communication was handled by a busy port, a message {monitor, SusPid, busy_dist_port, Port} is sent to MonitorPid. SusPid is the pid that got suspended when sending through the inter-node communication port Port.

system_profile也是提供些erts进程和port的信息
erlang:system_profile(ProfilerPid, Options) -> ProfilerSettings


Types:

ProfilerSettings -> {ProfilerPid, Options} | undefined
ProfilerPid = pid() | port()
Options = [Option]
  Option = runnable_procs | runnable_ports | scheduler | exclusive

Sets system profiler options. ProfilerPid is a local pid or port that will receive profiling messages. The receiver is excluded from all profiling. The second argument is a list of profiling options:

runnable_procs
    If a process is put into or removed from the runqueue a message, {profile, Pid, State, Mfa, Ts}, is sent to ProfilerPid. Running processes that is reinsertet into the runqueue after completing its reductions does not trigger this message.
runnable_ports
    If a port is put into or removed from the runqueue a message, {profile, Port, State, 0, Ts}, is sent to ProfilerPid.
scheduler
    If a scheduler is put to sleep or awoken a message, {profile, scheduler, Id, State, NoScheds, Ts}, is sent to ProfilerPid.
exclusive
    If a synchronous call to a port from a process is done, the calling process is considered not runnable during the call runtime to the port. The calling process is notified as inactive and subsequently active when the port callback return

erts_debug提供最详尽的内部数据信息
erts_debug:get_internal_state()未公开


node_and_dist_references
DbTable_words
next_pid
next_port
check_io_debug
available_internal_state
monitoring_nodes
link_list
monitor_list
channel_number
have_pending_exit

crash dump则是个无价之宝 可以用erlang:halt来强行产生系统的运行映像,分析系统的运行状态。

其他的几个机制如trace文档都写得很清楚,我就不抄书了。
4
2
分享到:
评论
1 楼 flyeverzhang 2008-12-09  
这是什么东东?

相关推荐

    Erlang 运行环境的安装文件

    此外,Erlang 还具有内置的错误处理机制,使得程序在遇到故障时能够自动恢复,增强了系统的稳定性和可靠性。 安装 Erlang 运行环境通常涉及以下步骤: 1. **下载**:访问 Erlang 官方网站 ...

    erlang-23.2.1-1.el7.x86-64.rpm

    Erlang:RabbitMQ 是用 Erlang 编写的,因此需要 Erlang 运行时。确保安装了兼容的 Erlang 版本;Erlang:RabbitMQ 是用 Erlang 编写的,因此需要 Erlang 运行时。确保安装了兼容的 Erlang 版本;Erlang:RabbitMQ ...

    erlang的timer和实现机制

    此外,提供的"erlang的timer和实现机制.pdf"和"更多erlang资料下载.txt"也是进一步学习和研究的好资源。 总之,Erlang的timer模块是其强大并发能力的一个体现,通过熟练掌握这一部分,开发者可以构建出更加高效和...

    erlang编程 Introducing Erlang

    BEAM是Erlang运行时系统的名称,全称为伯尔尼高级执行机器(Bergen Erlang Virtual Machine)。它负责解释Erlang字节码,提供内存管理、垃圾回收和并发调度等功能。 ### 10. 语言特性 Erlang的语法简洁,支持模式...

    Erlang深度分析

    ERTS是Erlang运行时系统,了解ERTS在运行期内存使用情况是优化Erlang应用的关键。这包括了解ETS(Erlang Term Storage)和Dets(Disk ETS)的使用,以及如何监控和调整内存分配。 ##### 3.2 Erlang中的调试工具 ...

    erlang_版本24.3.4.4

    - **错误处理**:Erlang采用异常处理机制,鼓励编写无副作用的纯函数,有助于编写容错性强的代码。 - **模式匹配**:Erlang的模式匹配功能允许在函数定义中使用模式来匹配和解构数据结构,简化了代码编写。 - **...

    erlang23.2版windows64位.zip

    6. **模式匹配**:Erlang的模式匹配机制使得解构复杂数据结构和条件分支变得简单。 7. **BEAM虚拟机**:Erlang运行在BEAM(Erlang虚拟机)上,BEAM为Erlang提供了高效的内存管理和垃圾回收。 8. **标准库**:OTP...

    erlang文献及资料汇总

    erlang文献及资料汇总 入门资料: erlang中文手册(R11B 文档译文,最适合入门) ...erlang VM内部数据共享机制 erlang 消息传递机制 文章地址:http://blog.csdn.net/mycwq/article/details/43115733

    inside Erlang VM3

    #### Erlang自省机制 - **Trace工具**:Erlang提供了强大的追踪工具,帮助开发者调试程序。 - **系统信息**:ERTS提供了丰富的运行时信息,包括CPU使用率、内存使用情况、GC活动等。 - **监控机制**:ERTS支持对进程...

    erlang资源

    4. **错误调试**:Erlang的错误处理机制,如shell的使用、日志和调试工具。 5. **REPL(Read-Eval-Print Loop)**:Erlang shell的使用,它是学习和测试Erlang代码的重要工具。 6. **实际应用案例**:可能包含...

    RabbitMQ3.9.13和ErLang24.2版本

    2. **容错性**:Erlang的错误恢复机制和热代码升级功能使得Erlang程序能在出现错误时优雅地重启,而不影响整个系统。这对于保持RabbitMQ的稳定性至关重要。 3. **分布式特性**:Erlang的分布式特性使得构建分布式...

    erlang深度分析.pdf

    Erlang的虚拟机(VM)即Erlang Runtime System(ERTS),是Erlang系统运行的基础。它支持轻量级进程,提供了高效的并发处理能力。在性能方面,ERTS经过优化,能够在多种硬件架构上高效运行。进行VM的定量分析是了解...

    Erlang编程

    - **容错性**:Erlang的容错机制包括无共享内存、无锁编程和热代码升级等,使得在部分系统故障时,整个系统可以继续运行。 4. **基本语法和概念**: - **安装Erlang**:要开始Erlang编程,首先需要在计算机上安装...

    Erlang 环境 opt_win64_21.1版本

    Erlang环境,如"opt_win64_21.1"版本,提供了在Windows平台上运行Erlang程序所需的基础组件。 OTP(Open Telephony Platform)是Erlang的开源开发框架,包含了Erlang虚拟机(BEAM)、库函数、编程模式和设计原则。...

    Programming Erlang

    Erlang的热加载特性使得代码更新和调试变得非常方便,这对于持续运行的系统尤其有用。 在分布式编程方面,《Programming Erlang》涵盖了节点间通信、分布式进程和分布式应用程序的构建。Erlang的BEAM虚拟机允许跨...

    erlang及其应用

    Erlang是一种通用编程语言和运行环境,专为并发性、分布性和容错性而设计。它最初由爱立信开发,用于大型电信系统。Erlang的特点使其特别适合构建分布式、可靠且具有软实时性的并发系统,如电话交换控制系统、互联网...

    otp-win64-25.0.1.exe ErLang 下载

    5. **垃圾回收机制**:ErLang的垃圾回收机制有效地管理内存,避免了常见的内存泄露问题。 6. **简洁的语法**:ErLang的函数式编程风格使得代码简洁明了,易于理解和调试。 **在Windows上安装和使用ErLang** 下载...

    erlang简介

    8. **多核心支持**:Erlang运行时系统(ERTS)充分利用多核CPU资源,通过调度器和进程分配策略,确保多处理器环境下的高效运行。 9. **IO处理**:Erlang的IO系统基于Unix哲学,将所有设备视为文件,支持多种IO模型...

    Erlang 20.3linux安装包

    在IT行业中,Erlang因其强大的实时性、并发性和内存管理机制而被广泛应用于网络通信、数据库系统以及消息中间件,如RabbitMQ。 RabbitMQ是一款基于AMQP(Advanced Message Queuing Protocol)协议的开源消息队列...

Global site tag (gtag.js) - Google Analytics