最近经常碰到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…
blkiomon 是blktrace工具包带的一个方便用户了解IO情况的工具, 由于blktrace太专业,需要了解的IO协议栈的东西太多,blkiomon给大多数的用户提供了一种易于使用的方式.
blktrace的使用参考这里: http://blog.yufeng.info/archives/tag/blktrace
他可以告诉你IO的大小,完成花费时间,吞吐量, 还可以统计出这次关键参数的分布.
具体见man blkiomon
blkiomon is a block device I/O monitor. It periodically generates per-device request size and request latency statistics from blktrace data. It
provides histograms as well as data that can be used to calculate min, max, average and variance. For this purpose, it consumes D and C traces
read from stdin.
我们来演示下:
Read more…
Linux下的pipe使用非常广泛, shell本身就大量用pipe来粘合生产者和消费者的. 我们的服务器程序通常会用pipe来做线程间的ipc通讯. 由于unix下的任何东西都是文件,只要是文件,在读取的时候,,就会设置last access time, 所以pipe也不例外., 但是这个时间对我们没有意义 如果pipe使用的非常频繁的时候会碰到由于设置访问时间导致的性能问题. 这个开销远比pipe读写的本身开销大. 相比文件读写的开销, atime微不足道,但是对pipe来讲就不同了.
这个事情是上次和多隆同学在把玩他的网络框架的时候,无意发现的.
我们来分析下pipe的这部分代码:
Read more…
互联网上的TCP服务器面对的环境情况比企业私有的服务器要复杂很多。常见的针对tcp服务器的攻击有以下几种：
1. 伪造协议，导致服务器crash. 比如说某条命令的字段长度，协议最大规定是1024，伪造个4096的。
2. 伪造大的报文，比如说一个包有1024M这么大。
3. 消耗服务器资源。开大量的连接， 以龟速发送报文，比如说每分钟一个字节。
4. DDOS攻击，从不同的IP发起大量的连接, 大流量淹没服务器。
5. 攻击Erlang集群的授权体系，all or nothing。
6. 报文发送顺序逻辑错误，导致服务器crash. 比如说逻辑上应该先发A，再发B, 攻击者调了顺序。
7. 不停的连接断开，消耗服务器对资源的申请和释放，这个通常很耗。
8. 篡改协议中关键时间事件，造成时间混乱。
9. 利用协议中需要大量计算和资源的事件攻击。
10. 利用协议的安全漏洞或者实现系统的漏洞，比如说erlang的atom个数的限制，对系统造成威胁。
11. Hash Collision DoS 等攻击。
12. term_to_binary数据深度太大，底层VM实现用的是c的递归，很容易导致stack overflow。
13. Mnesia数据库各role对等, 很容易在其中一个节点发起数据破坏操作。
14. 大量的请求涌入，导致大量消息产生，消息队列爆了。
15. 利用inets底层实现的漏洞，构造些畸形数据导致inet drv工作异常。
16. 攻击系统的RPC通道，节点间的RPC通道只有一条容易饱和。
17. 攻击系统的NIF实现漏洞，导致VM crash。
等等，有很多方法。
那我们的Erlang版的TCP服务器如何应对这些情况呢？
Read more…
Recent Comments