新发布的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) [source] [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…
在新的NUMA体系结构下，每个CPU都有自己的本地内存，如果要访问其他CPU的内存，那算remote了，要走CPU之间的QPI通道，通常这样速度会有40%的下降。
那么对于多线程的程序来讲，这个硬件的变化对软件也有很大的影响。在多线程程序里面，通常一个线程会为一个对象分配内存，然后把这个对象传递到不同的线程去使用，最后由其他线程释放内存。而这二个线程可能在不同的CPU上运行，这个场景很普遍，比如说Erlang的消息机制。如果谁创建谁释放对象，提高内存倒腾的效率，那么对于消息密集型程序会有很多帮助。
R15的最大的运行期优化见： 这里
这个特性也就是之前声称的delayed dealloc特性
对照下OTP团队之前的规划：
目前规划里面的1，2，3，4在R15里面都已经实现了。
Optimize memory allocation
A number of memory allocation optimizations have been implemented. Most
optimizations reduce contention caused by synchronization between
threads during allocation and deallocation of memory. Most notably:
* Synchronization of memory management in scheduler specific allocator
instances has been rewritten to use lock-free synchronization.
* Synchronization of memory management in scheduler specific
pre-allocators has been rewritten to use lock-free synchronization.
* The ‘mseg_alloc’ memory segment allocator now use scheduler specific
instances instead of one instance. Apart from reducing contention
this also ensures that memory allocators always create memory
segments on the local NUMA node on a NUMA system.
我们来尝鲜演示下，首先设计个消息密集型的程序：
Read more…
Linux下的pipe使用非常广泛, shell本身就大量用pipe来粘合生产者和消费者的. 我们的服务器程序通常会用pipe来做线程间的ipc通讯. 由于unix下的任何东西都是文件,只要是文件,在读取的时候,,就会设置last access time, 所以pipe也不例外., 但是这个时间对我们没有意义 如果pipe使用的非常频繁的时候会碰到由于设置访问时间导致的性能问题. 这个开销远比pipe读写的本身开销大. 相比文件读写的开销, atime微不足道,但是对pipe来讲就不同了.
这个事情是上次和多隆同学在把玩他的网络框架的时候,无意发现的.
我们来分析下pipe的这部分代码:
Read more…
Recent Comments