Archive

Author Archive

很容易忽略的ETS表个数限制问题

November 30th, 2011 Comments off

最近经常碰到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…

Categories: Erlang探索 Tags: ,

Erlang open_port极度影响性能的因素

November 22nd, 2011 4 comments

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…

Erlang R15的内存delayed dealloc特性对消息密集型程序的影响

November 21st, 2011 1 comment

在新的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…

Categories: Erlang探索, 调优 Tags: ,

IO模式调查利器blkiomon介绍

November 9th, 2011 Comments off

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…

Categories: Linux, 工具介绍, 调优 Tags: ,

Linux下pipe使用注意事项

November 9th, 2011 13 comments

Linux下的pipe使用非常广泛, shell本身就大量用pipe来粘合生产者和消费者的. 我们的服务器程序通常会用pipe来做线程间的ipc通讯. 由于unix下的任何东西都是文件,只要是文件,在读取的时候,,就会设置last access time, 所以pipe也不例外., 但是这个时间对我们没有意义 如果pipe使用的非常频繁的时候会碰到由于设置访问时间导致的性能问题. 这个开销远比pipe读写的本身开销大. 相比文件读写的开销, atime微不足道,但是对pipe来讲就不同了.
这个事情是上次和多隆同学在把玩他的网络框架的时候,无意发现的.

我们来分析下pipe的这部分代码:
Read more…

Erlang版TCP服务器对抗攻击解决方案

November 3rd, 2011 21 comments

互联网上的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…

Categories: Erlang探索, 网络编程 Tags:

Flashcache使用的误区以及解决方案

October 28th, 2011 6 comments

flashcache是facebook释放出来的开源的混合存储方案,用ssd来做cache提升IO设备的性能.很多硬件厂商也有类似的方案,比如说LSI raid卡. 但是这个方案是免费的软件方案,而且经过产品的考验,具体参见:
主页:https://github.com/facebook/flashcache
开源混合存储方案(Flashcache): http://blog.yufeng.info/archives/1165
Flashcache新版重大变化: http://blog.yufeng.info/archives/1429

但是flashcache在使用中很多人会有个误区,导致性能很低。首先我们看下flashcache的设计背景和适用场景:

Introduction :
============
Flashcache is a write back block cache Linux kernel module. This
document describes the design, futures ideas, configuration, tuning of
the flashcache and concludes with a note covering the testability
hooks within flashcache and the testing that we did. Flashcache was
built primarily as a block cache for InnoDB but is general purpose and
can be used by other applications as well.

它是为数据库这样的应用的离散读写优化。如果你用在了顺序读写,就有非常大的性能问题。
那么为什么呢?我来分析下:

flashcache把内部的cache空间分成很多set, 是以set而不是整体为单位提供cache以及flush后备操作. 也就是说当一个set里面的dirty page达到一个预设的值的时候,就需要把这么dirty page 淘汰并且flush到后备设备去,以便腾出空间给更热的数据使用。
那么每个set多大呢?

To compute the target set for a given dbn
target set = (dbn / block size / set size) mod (number of sets)
Once we have the target set, linear probe within the set finds the
block. Note that a sequential range of disk blocks will all map onto a
given set.

set默认是 512*4k = 2M大小,也就是说如果你的这个set刚好是一个文件所在的块,而且每次这个文件都不停的顺序写,很快这个set都变成dirty, 那么flashcache就选择马上刷,这样加速效果就没有了。

幸好作者Mohan认识到了这个问题,提供了解决方案:

见https://github.com/facebook/flashcache/blob/master/doc/flashcache-sa-guide.txt 中的章节Tuning Sequential IO Skipping for better flashcache performance

引入了配置参数来解决这个问题:

dev.flashcache..skip_seq_thresh_kb:
Skip (don’t cache) sequential IO larger than this number (in kb).
0 (default) means cache all IO, both sequential and random.
Sequential IO can only be determined ‘after the fact’, so
this much of each sequential I/O will be cached before we skip
the rest. Does not affect searching for IO in an existing cache.

这样你可以把太大的顺序操作给过滤掉了,大大提升性能。

祝玩得开心!