Erlang非业余研究

最新的Erlang虚拟机（R15B01）很大的一个改进就是加入了对dtrace探测点的支持了， 具体参见这里, 主要目标是方便在生产实践中定位复杂的性能问题。

目前Erlang的虚拟机的探测点支持Linux的systemtap和freebsd的dtrace，我们刚好能够享受的到。

作者Scott Lystig Fritchie在去年的euc中做了个很有意思的报告，参见这里，该PPT很详细的介绍了利用dtrace的探测点可以观察到erlang的行为如下：

Processes: spawn, exit, hibernate, scheduled, …
Messages: send, queued, received, exit signals
Memory: GC minor & major, proc heap grow & shrink
Data copy: within heap, across heaps
Function calls: function & BIF & NIF, entry & return
Network distribution: monitor, port busy, output events
Ports: open, command, control, busy/not busy
Drivers: callback API 100% instrumented
efile_drv.c fifile I/O driver: 100% instrumented

这些探测点基本上属于IO，进程调度，消息发送，driver等虚拟机最底层的和操作系统耦合的部分，对性能的影响巨大。

目前Erlang自己的基础设施并没有涵盖到这部分内容，如dbg,trace机制都无法了解到这些数据，导致在大型的集群系统里面一旦发现性能问题无法很好的展开调查，所以这些探测点刚好填补了空白。

目前这些dtrace probe点是用static marker实现的，细节可以参看这里 和 这里，好处是不用这些特性的时候，不会对性能有任何的影响，只需要为使用付代价。目前支持这种机制的语言和系统有java,python,mysql,pgsql等，可见威力强劲。

好拉，废话少说，我们来体验下。
Read more…

今天和项仲在部署新系统的时候发现节点间ping不成功的情况，类似

1> net_adm:ping(‘xx@ip1′).
pang

由于这个问题比较普遍，我就记录下一步步的排除步骤.

首先从原理上分析下!由于erlang节点间通讯是透过tcp来进行的，所以我们确保以下几点：
1. 确保网络连接是通的，可以透过ping来查看。
2. 确保网络连接上tcp是可以通的，可以透过netcat在二个节点所在的机器上分别开个服务器端和客户端进行验证。
3. 确保端口是防火墙友好的。erlang的节点是登记在epmd服务上的，所以4369端口要能访问，其次节点的动态端口是可以访问的。

epmd -names
epmd: up and running on port 4369 with data:
name xx at port 46627
…

同样可以用netcat来验证。
4. erlang节点的cookie是一样的，可以透过setcookie来解决。

这几点确认无误后，就可以开始排查问题了。
首先交代下环境，二台机器IP分别是10.1.150.12,10.232.31.89, 上面分别运行Erlang版本R16B和R14B04，cookie统一设置为456789。
接着我们来演习下，首先我们10.1.150.12在节点A上起个节点’xx@10.1.150.12′，如下：

Read more…

新发布的R15B在亮点里面提到：

There is a new GUI tool in the observer application which integrates pman, etop, appmon and tv into one tool. The tool does also contain functions for activating tracing in an easy way.

这个observer完全用wx重新改写过，界面操作速度非常块，整合了几个常用的观察工具，很方便用户，我们来尝鲜下：

$ erl
Erlang R15B (erts-5.9) 1 [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.9  (abort with ^G)
1> observer:start().
ok

上截图：
Read more…

Erlang虽然号称N个9的稳定性，但是在实际使用中还是有很多机会看到Erlang Crash了的，其中和VM相关的Crash 十有八九是由于内存使用过量，导致系统服务分配内存导致的。Erlang的内存分配测量是集中批发，零售给各个VM部件，包括用户进程和ETS数据库等内存消费大户。VM的内存增长是以fib方式上升的，一旦你的内存使用到G级别，那么之后的大量内存分配会以超过你预想的速度消费。

其中用户进程的消息队列是其中的罪魁祸首。 Erlang的虚拟机实现和设计上都没有阻止用户往一个进程的消息队里面扔消息，当消息的生产速度过快，超过进程的处理能力，这些消息就堆积起来，占用越来愈多的内存，最终导致VM崩溃。

那么我们如何来避免这种事情呢？既然不能阻止，那我们绕着走，通过监控来避免：
1. 监控消息队列的增长。
2. 监控VM整个内存的使用量。
Read more…

最近我们为了安全方面的原因，在RDS服务器上做了个代理程序把普通的MYSQL TCP连接变成了SSL链接，在测试的时候，皓庭同学发现Tsung发起了几千个TCP链接后Erlang做的SSL PROXY老是报告gen_tcp:accept返回{error, enfile}错误。针对这个问题，我展开了如下的调查：

首先man accept手册，确定enfile的原因，因为gen_tcp肯定是调用accept系统调用的:

EMFILE The per-process limit of open file descriptors has been reached.
ENFILE The system limit on the total number of open files has been reached.

从文档来看是由于系统的文件句柄数用完了，我们顺着来调查下：

$ uname -r
2.6.18-164.el5
$ cat /proc/sys/fs/file-nr
2040    0       2417338
$ ulimit -n
65535

由于我们微调了系统的文件句柄，具体参考这里 老生常谈: ulimit问题及其影响， 这些参数看起来非常的正常。
先看下net/socket.c代码：
Read more…

最近经常碰到ets表使用的数目超过系统的限制导致Erlang应用异常的案例。 比如说神锋同学报告说在ssh模块里面，最多只能打开500个左右链接，系统空闲的很，但是无法继续加大链接。 浩庭同学报告说mnesia的事务只能开1千多，多了就上不去了。这些问题看起来没有关联。但是其实和ets都有很大的关系,而且会报system_limit错误。

Erlang系统的限制见这里： http://www.erlang.org/doc/efficiency_guide/advanced.html#id215064
其中和ets相关的：

Ets table 内存消耗
Initially 768 words + the size of each element (6 words + size of Erlang data). The table will grow when necessary.

Ets-tables
The default is 1400, can be changed with the environment variable ERL_MAX_ETS_TABLES.

这个值非常的偏保守，我们通常的服务器都有几十G的内存，因为ETS基本是消耗内存的，所以我们不介意都开大点。

回到前面的问题，ssh出问题的原因是它每个链接需要3个ets, 而mnesia一个事务也要消耗1个ets表。
Read more…

Erlang的port相当于系统的IO，打开了Erlang世界通往外界的通道，可以很方便的执行外部程序。 但是open_port的性能对整个系统来讲非常的重要，我就带领大家看看open_port影响性能的因素。

首先看下open_port的文档：

{spawn, Command}

Starts an external program. Command is the name of the external program which will be run. Command runs outside the Erlang work space unless an Erlang driver with the name Command is found. If found, that driver will be started. A driver runs in the Erlang workspace, which means that it is linked with the Erlang runtime system.

When starting external programs on Solaris, the system call vfork is used in preference to fork for performance reasons, although it has a history of being less robust. If there are problems with using vfork, setting the environment variable ERL_NO_VFORK to any value will cause fork to be used instead.

For external programs, the PATH is searched (or an equivalent method is used to find programs, depending on operating system). This is done by invoking the shell och certain platforms. The first space separated token of the command will be considered as the name of the executable (or driver). This (among other things) makes this option unsuitable for running programs having spaces in file or directory names. Use {spawn_executable, Command} instead if spaces in executable file names is desired.

open_port一个外部程序的时候流程大概是这样的：beam.smp先vfork, 子进程调用child_setup程序，做进一步的清理操作。 清理完成后才真正exec我们的外部程序。

再来看下open_port实现的代码：
Read more…