Erlang tool -- recon

遇见recon 以来, 每次定位系统瓶颈, 总是能让我眼前一亮. 比如说, 定位非尾递归导致的内存暴涨, 定位引发CPU满载的进程.得心应手,每每额手称庆.

recon 是ferd 大神 释出的一个 用于生产环境诊断Erlang 问题的一个工具, 不仅仅是对Erlang stdlib 接口的封装, 还有memory fragmentation 相关的函数.

CPU 统计相关

在ferd 大神放出的 Erlang_In_Anger 中提到了

The reduction count has a direct link to function calls in Erlang, and a high count is usually the synonym of a high amount of CPU usage.

What’s interesting with this function is to try it while a system is already rather busy, with a relatively short interval. Repeat it many times, and you should hopefully see a pattern emerge where the same processes (or the same kind of processes) tend to always come up on top.

Using the code locations and current functions being run, you should be able to identify what kind of code hogs all your schedulers.

引用中提到的"this function" 是:

1> recon:proc_window(reductions, 3, 500).

也就是说, 将某个进程在一段时间内的reductions 变化大小作为这一段时间内该进程消耗CPU的程度.

Memory Leaks

memory leaks 主要是 refc binary, 这一点主要是和binary 的内存结构有关, 之前写的一篇blog  有提到这个.

解决的方式 ferd 也有一些建议:

Once you’ve established you’ve got a binary memory leak using recon:bin_leak(Max) , it should be simple enough to look at the top processes and see what they are and what kind of work they do.
Generally, refc binaries memory leaks can be solved in a few different ways, depending on the source:

• call garbage collection manually at given intervals (icky, but somewhat efficient);

• stop using binaries (often not desirable);

• use binary:copy/1-210 if keeping only a small fragment (usually less than 64 bytes) of a larger binary;

• move work that involves larger binaries to temporary one-off processes that will die when they’re done (a lesser form
of manual GC!);

• or add hibernation calls when appropriate (possibly the cleanest solution for inactive processes).


The first two options are frankly not agreeable and should not be attempted before all else failed. The last three options
are usually the best ones to be used. 

第一种方案rabbitmq 其实是在使用的, 第二种基本上不太可能, 第三种应该在代码中多加注意, 第四种也就是尽可能使用Erlang VM 所倡导的short-lived 进程, 第五种也就是进程hibernate 方案同样在之前写的一篇blog中有提到 .

Memory Fragmentation

内存碎片和Erlang 虚拟机内存管理方式有很大的关系, 也就是内存泄露, 最明显的现象就是erlang:memory() 显示出来的内存使用量远远小于操作系统报告出来(如 top)的使用量.

总结

recon 是个实际操作性很强的工具, 没有实际的使用案例, 很难说得清楚它的妙用.

基友们有啥问题, 可以提出来, 大家一起交流.

时间: 2024-10-26 16:24:05

Erlang tool -- recon的相关文章

Erlang tool -- lager overload protection

log 这个事, 说大不大说小又不小. 大点的, 可以用scribe flume 这样的系统去做, 小点的, 也就打印一个调试信息而已. 在Erlang 中, log 这事情确实比较伤, error_logger 是个单点, io:format 容易导致节点崩溃. 在开源社区, lager 算是使用比较广泛的一个, 然而, 同样不能完全避免单点的问题. 因为在lager 中, lager_event 作为 core, 是单个进程存在的. 1 dispatch_log(Severity, Meta

Erlang库 -- 有意思的库汇总

首先,库存在的目的大致可分为:1.提供便利2.尽可能解决一些痛点 首先,我们先明确一下Erlang编程语言的一些痛点(伪痛点):1,单进程问题Erlang虚拟机属于抢占式调度,抢占式调度有很多好处,但是同样也存在这弊端.虚拟机在默认情况下分配个每个进程的资源都是相同的,但是若一个进程(gen_server/event/fsm)要为其他许多进程提供服务,这个进程就极有可能成为整个Erlang系统的瓶颈所在.http://www.cnblogs.com/--00/p/4277640.html2,列表

[Erlang_Question33]使用recon从网页查看Erlang运行状态

0.需求分析 Erlang最好的卖点之一就是提供了一个非常强大的shell来查看Node运行时的各种状态,可以进行各种各样的内部查看,在运行时调试和分析,热更新代码. 但是总有一些在生产环境下要慎用的状态查看函数.比如: 1.在进程数达到10w级以上的Node调用erlang:processes()来得到所有的进程Pid.然后算长度blabla...; 2. 当某个进程的信箱被堵塞了上万个消息队列时调用erlang:process_info(Pid,messages)来查看所有的消息. 为了避免

[Erlang危机](2.1)项目结构

?? 原创文章,转载请注明出处:服务器非业余研究http://blog.csdn.net/erlib 作者Sunface Project Structure The structures of OTP applications and of OTP releases are different. An OTP application can be expected to have one top-level supervisor (if any) and possibly a bunch of

Erlang 虚拟机内的内存管理(Lukas Larsson演讲听写稿)

Erlang核心开发者Lukas Larsson在2014年3月份Erlang Factory上的一个演讲详细介绍了Erlang内存体系的原理以及调优案例: http://www.erlang-factory.com/conference/show/conference-6/home/#lukas-larsson 在这里可以下载slides和观看视频(为了方便不方便科学上网的同学,我把视频搬运到了 http://v.youku.com/v_show/id_XNzA1MjA0OTEy.html )

[Erlang_Question31]Erlang trace总结

在一个并行的世界里面,我们很难做到单步断点调试来定位问题(太多的消息飞来飞去),Erlang设计者也深刻体会到这一点,推出了另一个trace机制. 通过这个trace,你可以: 1.指定进程内的函数调用输入输出,收发消息; 2.指定端口的输入输出,收发消息. 这样你就可以不加一行代码(抛弃那类io:format的烦琐又单一的方法吧),不影响正常运行的系统来(在一个服务器系统里面单步断点几乎是不可行的),就查看到你想要了解的控制流程. 现在Erlang用于Trace的库有: • sys  come

Rebar:Erlang构建工具

Rebar:Erlang构建工具 http://www.cnblogs.com/panfeng412/archive/2011/08/14/2137990.html Rebar是一款Erlang的构建工具,使用它可以方便的编译.测试erlang程序.内联驱动和打包Erlang发行版本. Rebar是一个独立的erlang脚本,所以使用Rebar发布程序非常简单,甚至可以直接集成在项目文件夹中.默认的情况下,Rebar会按照Erlang/OTP来组织项目的结构,这样一来,构建时的配置工作量就会大大

[Erlang危机](5.1.1)内存

原创文章,转载请注明出处:server非业余研究http://blog.csdn.net/erlib 作者Sunface 联系邮箱:[email protected] Memory The memory reported by the Erlang VM in most tools will be a variant of what is reported by erlang:memory() : Erlang VM大多数检測内存的工具都是通过erlang:memory()来实现的. -----

recon工具解读

recon 是ferd 大神 释出的一个 用于生产环境诊断Erlang 问题的一个工具, 不仅仅是对Erlang stdlib 接口的封装, 还有memory fragmentation 相关的函数. 下面对rencon的各个函数进行解读,做个笔记 -module(recon). -export([info/1, info/2, info/3, info/4, proc_count/2, proc_window/3, bin_leak/1, node_stats_print/2, node_st