系统技术非业余研究

R16B发布的时候，其中一个很大的亮点就是R16B port并行机制, 摘抄官方的release note如下：

— Latency of signals sent from processes to ports — Signals
from processes to ports where previously always delivered
immediately. This kept latency for such communication to a
minimum, but it could cause lock contention which was very
expensive for the system as a whole. In order to keep this
latency low also in the future, most signals from processes
to ports are by default still delivered immediately as long
as no conflicts occur. Such conflicts include not being able
to acquire the port lock, but also include other conflicts.
When a conflict occur, the signal will be scheduled for
delivery at a later time. A scheduled signal delivery may
cause a higher latency for this specific communication, but
improves the overall performance of the system since it
reduce lock contention between schedulers. The default
behavior of only scheduling delivery of these signals on
conflict can be changed by passing the +spp command line flag
to erl(1). The behavior can also be changed on port basis
using the parallelism option of the open_port/2 BIF.

而且Jeff Martin同学也在qcon上发表了一篇文章特地提到这个事情，英文版见这里，中文版见这里

那么到底什么是R16B port并行机制呢？简单的说就是erl的这个选项：

+spp Bool
Set default scheduler hint for port parallelism. If set to true, the VM will schedule port tasks when it by this can improve the parallelism in the system. If set to false, the VM will try to perform port tasks immediately and by this improve latency at the expense of parallelism. If this flag has not been passed, the default scheduler hint for port parallelism is currently false. The default used can be inspected in runtime by calling erlang:system_info(port_parallelism). The default can be overriden on port creation by passing the parallelism option to open_port/2

作用呢？我们知道每个port都会有个锁来保证送给port的消息的先来后到，当有多个进程给port发送消息的话，必然要排队等前面的消息处理完毕。这是比较正常的行为。但是Erlang设计的哲学就是消息和异步通信，进程好好的时间浪费在排队上面总是不太爽。所以就搞了个port并行机制. 当进程发现需要排队的时候，他就把消息扔给port调度器，他自己就该干啥干啥去了，反正消息是异步的，他相信port调度器会把消息投递到。port调度器拿到用户委托的消息后，择机调度请求port去完成具体的任务。

类比下现实生活的例子。 比如说我去邮局寄快递，比如顺风快递，我寄了后，他会给我一个邮单号码，时候顺风会通知我邮包的情况，当然我也可以用这个邮单号码主动去查询状态。我到邮局一看，顺风快递的柜台只有一个工作人员在忙，而且寄东西人的队伍比较排很长了，这时候我有二个选择： 1. 在队伍的后面排队。 2. 我请求邮局的工作人员（比如保安）（当然可以给点小费）把我的邮包先收下，在寄东西人少的时候帮我寄下，而我就可以走了。 虽然我多花钱了，但是我花在上面的时间少了，这个小费可以挣的回来的。

port并行机制也是类似的原理。启用这个机制有二种方法：
1. 全局的。erl +spp Bool
2. per port的。open_port(PortName, PortSettings)的时候打开{parallelism, true}选项。

但是任何事情都有二面性。打开这个选项后需要注意什么呢？

我们还是拿前面的寄快递的例子来看，如果每个人都象我这样的都把邮包委托给保安去寄的话，那人多的话会有什么情况呢？保安那边有成堆的邮件，他领导一看，肯定要生气了，所以保安肯定会限制邮包数目。超过了，他就不接了。所以这就是调度器的水位线。而且顺风快递工作人员也有水位线，不如全杭州的人都来寄邮件他受的了？

那这二个水位线分别是多少呢？ 我之前写的这篇文章 gen_tcp发送缓冲区以及水位线问题分析 解释的很清楚，我简单的复述下：

1. port自己的水位线，比如说inet_tcp是：
#define INET_HIGH_WATERMARK (1024*8) /* 8k pending high => busy */
#define INET_LOW_WATERMARK (1024*4) /* 4k pending => allow more */

这个水位线可以透过inet:setopts选项来设置：
{low_watermark, Size}
{high_watermark, Size} (TCP/IP sockets)

2. MSGQ高低水位线也是8/4K，最小值是1， 高不封顶。当然也有选项可以设置。
{high_msgq_watermark, Size}
{low_msgq_watermark, Size}

这篇文章还解释了“A signal delivery”这个动作。每个port都要把消息发送出去处理了才有意义，那么这个发送动作其实就是call_driver_outputv， 调用port特有的driver_outputv回调函数去做实际的事情。说白了port并行机制就是控制什么时候调用call_driver_outputv, 从原来的直接调，改成如果条件不合适，就让port调度器线程择机来调用。

小结：通过port并行机制可以大大提高整个VM中大量port的吞吐量，对于port或者网络密集型(gen_tcp就是个port)的应用会有很大的帮助。

祝玩得开心！

Erlang从R13B03开始引入了vheap的概念，具体参见这篇文章：R13B03 binary vheap有助减少binary内存压力
官方的release note里面简单的解释了下：

OTP-8202 A new garbage collecting strategy for binaries which is more
aggressive than the previous implementation. Binaries now has
a virtual binary heap tied to each process. When binaries are
created or received to a process it will check if the heap
limit has been reached and if a reclaim should be done. This
imitates the behavior of ordinary Erlang terms. The virtual
heaps are grown and shrunk like ordinary heaps. This will
lessen the memory footprint of binaries in a system.

但除此之外，无法找到更细的文档。最近在做的服务器程序里面用到了大量的binary, 需要对binary的行为做详细的分析，所以就顺便把vheap好好整理下。

我们首先看下如何控制vheap.
首先看下全局的设置， 参见这里

+hmbs Size
Sets the default binary virtual heap size of processes to the size Size.

如果不设定的话，这个值默认是：

./erl_vm.h:62:#define VH_DEFAULT_SIZE 32768 /* default virtual (bin) heap min size (words) */

我们来验证下我们的设置：

Erlang R16B03 (erts-5.10.4) [source-73d1b4a] [64-bit] [smp:16:16] [async-threads:10] [hipe] [kernel-poll:false]

Eshell V5.10.4  (abort with ^G)
1>  erlang:system_info(min_bin_vheap_size).
{min_bin_vheap_size,46422}

oops, 怎么对不起来呢？
看下代码，原来在erl_init里面会对这个值再进行调整：
Read more…

Erlang程序是非常健壮的，通常一个典型的虚拟机里面跑很多进程，这些进程即使有bug，按照erlang的哲学是快速死掉，系统留下异常堆栈，很容易发现问题。照理说erlang是很少crash的，但实际情况不是这样的。

在erlang VM crash的案例中，我们会发现大部分的网络服务器的原因都是binary内存不够申请不出来，所以内存短缺是最致命的影响稳定的因素。通常设计良好的erlang程序，按照otp的设计哲学不会占用太多内存的，即使占用了gc也很快就会回收的，除了binary这个内存使用大户。

比如说网络服务器程序，我们用binary来保存用户的封包，我们无法预测用户要发送多大的包，比如上限是50M，如果我们的系统有1000个这样的用户，在极端情况下，我们是要耗用50G内存的。通常在这种情况下，我们拿不出这么多物理内存，然后crash就很大概率会发生。

调查哪些进程用掉了最多的binary内存就很有必要了，我们在极端情况下，可以选择性的杀掉这些内存，保护自己不至于毁灭。

erlang:process_info有个未公开的选项 binary用来获取这个进程拥有的binary情况。

我们看下它的实现：

static Eterm
bld_bin_list(Uint **hpp, Uint *szp, ErlOffHeap* oh)
{
    struct erl_off_heap_header* ohh;
    Eterm res = NIL;
    Eterm tuple;

    for (ohh = oh->first; ohh; ohh = ohh->next) {
        if (ohh->thing_word == HEADER_PROC_BIN) {
            ProcBin* pb = (ProcBin*) ohh;
            Eterm val = erts_bld_uword(hpp, szp, (UWord) pb->val);
            Eterm orig_size = erts_bld_uint(hpp, szp, pb->val->orig_size);

            if (szp)
                *szp += 4+2;
            if (hpp) {
		Uint refc = (Uint) erts_smp_atomic_read_nob(&pb->val->refc);
                tuple = TUPLE3(*hpp, val, orig_size, make_small(refc));
                res = CONS(*hpp + 4, tuple, res);
                *hpp += 4+2;
            }
        }
    }
    return res;
}


Eterm
process_info_aux(Process *BIF_P,
                 Process *rp,
                 Eterm rpid,
                 Eterm item,
                 int always_wrap)
{
 ...
   case am_binary: {
        Uint sz = 3;
        (void) bld_bin_list(NULL, &sz, &MSO(rp));
        hp = HAlloc(BIF_P, sz);
        res = bld_bin_list(&hp, NULL, &MSO(rp));
        break;
    }
...
}

这个选项会返回一个bin情况tuple的列表，每个tuple的第一个是binary的地址，第二个是大小，第三个是引用次数。

我们来演示下如何使用：
Read more…

百岁同学说：

今天公司技术比武，比赛题目是给一个1.1g的大文本，统计文本中词频最高的前十个词。花了两天用erlang写完了代码，但是放到公司16核的机器上这么一跑，结果不比不知道，一比吓一条。erlang写的代码执行时间花了55秒左右，同事们有的用java，有的用C，还有的用C++，用C最快一个老兄只花了2.6秒，用java的也只用了3.2秒。相比之下erlang的代码，真是一头大蜗牛，太慢了。

详细参见这篇文章：http://www.iteye.com/topic/1131748

读取文件并且分析这是很多脚本语言如perl, python,ruby经常会干的事情.这个同学的问题是很普遍的问题，不只一个人反映过慢的问题。
今天我们来重新来修正下这个看法， 我们用数据说话。

首先我们来准备下文件, 这个文件是完全的随机数，有1G大小：

$ dd if=/dev/urandom  of=test.dat count=1024 bs=1024K
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 188.474 s, 5.7 MB/s
$ time dd if=test.dat of=/dev/null 
2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB) copied, 1.16021 s, 925 MB/s

real    0m1.162s
user    0m0.219s
sys     0m0.941s
$ time dd if=test.dat of=/dev/null bs=1024k
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.264298 s, 4.1 GB/s

real    0m0.266s
user    0m0.000s
sys     0m0.267s

我们准备了1G大小左右的文件，由于用的是buffered io, 数据在准备好了后，全部缓存在pagecache里面，只要内存足够，这个测试的性能和IO设备无关。 我们试着用dd读取这个文件，如果块大小是4K的话，读取这个文件花了1.16秒，而如果块大小是1M的话，0.26秒，带宽达到4.1GB每秒，远超过真实设备的速度。

那么我们用erlang来读取下这个文件来比较下，我们有三种读法：
1. 一下子读取整个1G文件。
2. 一个线程一次读取1块，比如1M大小，直到读完。
3. 多个线程读取，每个读取一大段，每次读取1M块大小。
然后比较下性能。

首先普及下背景：
1. erlang的文件IO操作由efile driver来提高，这个driver内部有个线程池，大小由+A 参数控制，所以IO是多线程完成的。
2. erlang的文件分二种模式： 1. raw模式 2. io模式 在raw模式下，数据直接由driver提供给调用进程， io模式下数据先经过file_server做格式化，然后再给调用进程。
3. 数据可以以binary和list方式返回，list方式下文件内容的byte就是一个整数，在64位机器上占用8个字节内存。
Read more…

我们知道TCP socket有发送缓冲区和接收缓冲区，这二个缓冲区都可以透过setsockopt设置SO_SNDBUF，SO_RCVBUF来修改，但是这些值设多大呢？这些值和协议栈的内存控制相关的值什么关系呢？
我们来解释下：

$ sysctl net|grep mem
net.core.wmem_max = 131071
net.core.rmem_max = 131071
net.core.wmem_default = 124928
net.core.rmem_default = 124928
net.core.optmem_max = 20480
net.ipv4.igmp_max_memberships = 20
net.ipv4.tcp_mem = 4631520 6175360 9263040
net.ipv4.tcp_wmem = 4096 16384 4194304
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.udp_mem = 4631520 6175360 9263040
net.ipv4.udp_rmem_min = 4096
net.ipv4.udp_wmem_min = 4096

下面的图很好的解释了上面的问题：

这里要记住的是：TCP协议栈内存是不可交换物理内存，用一字节少一字节。
也正是由于这一点，操作系统出厂的时候上面的默认的内存设置都不算太大。对于一个不是网络密集型的服务器问题不大，但是对于如承担C1M链接的服务器来讲，问题就来了。我们在实践中会发现tcp服务经常超时，有时候超过100ms. 那么这个问题如何定位呢？
Read more…

随着PCI-E SSD卡的普及，很多高性能的服务器都用上了如fusionio这样的设备来提升IO的性能，这样会带来一些问题。 这些高速的IO设备在运作的时候会产生大量的中断来通知IO的完成，全速运转的系统上中断达到14000irqs/sec 如图：

而中断是默认摊到所有的CPU:

#cat /proc/irq/1/smp_affinity
ffffffff

在实践中来看会落在最繁忙的0核心上，这样就会给性能雪上加霜,效果如下：

cat /proc/interrupts |grep fct
144: 39913474 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge iodrive-fct0
145: 44976079 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge iodrive-fct1

中断144，145属于iodrive-fct高速设备的，都落在了0号核心上。

对于大多数的高性能服务器通常都有16-32个核心，越靠后面的核心越闲，那为什么我们不把中断移到后面的核心，让核心0解放出来多做其他的事情呢？毕竟由于历史原因，很多东西还是在核心0上做的，减负！

这个问题的核心就是要设置/proc/N/145/smp_affinity的CPU掩码， 手工做比较麻烦。

好了，脚本来了：

# cat set_fio_affinity.sh 
#!/bin/bash

set_affinity()
{
    MASK_TMP=$((1<<(`expr $VEC + $CORE`)))
    MASK=`printf "%X" $MASK_TMP`
    printf "%s mask=%s for /proc/irq/%d/smp_affinity\n" $DEV$VEC $MASK $IRQ
    printf "%s" $MASK > /proc/irq/$IRQ/smp_affinity
}


if [ $# -ne 1 ] ; then
    echo "usage:"
    echo "    $0 core "
    exit
fi

CORE=$1
DEV="iodrive-fct"
MAX=`grep -i $DEV /proc/interrupts | wc -l`
if [ "$MAX" == "0" ] ; then
    echo no $DIR vectors found on $DEV
    exit
fi

for VEC in `seq 0 1 $MAX`
do
    for IRQ in `cat /proc/interrupts | grep -i $DEV$VEC|cut  -d:  -f1| sed "s/ //g"`
    do
        set_affinity
    done
done

# ./set_fio_affinity.sh 30 
iodrive-fct0 mask=40000000 for /proc/irq/144/smp_affinity
iodrive-fct1 mask=80000000 for /proc/irq/145/smp_affinity

再cat /proc/interrupts看下实践效果就可以看到后面的核心已经有中断了，而且0号核心上的数字没变!

# perf top –cpu=31

也验证了这一点：

另外一姐妹篇 “MYSQL数据库网卡软中断不平衡问题及解决方案” 参见 这里！

祝玩的开心！

刚@淘宝雕梁 告诉我 GLIBC 2.16 支持systemtap静态检查点，消息源在这里， 摘抄相关部分如下：

* New configure option –enable-systemtap builds SystemTap static probes
into libc for setjmp and longjmp and into libpthread for various operations.
So far the setjmp/longjmp probes and some of the libpthread probes are
provided only for i*86 and x86_64.
Implemented by Roland McGrath and Rayson Ho.

目前主要是在setjmp/longjmp和pthread相关的锁操作，而且只支持 i*86 and x86_64 平台。我们到源码验证下：
Read more…