原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: Erlang R15B 全新的observer

新发布的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

上截图：

系统信息:

Appmon:

Etop:

Tv:

Pman:

界面看起来很清爽！

祝玩得开心！

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: Erlang虚拟机内存使用问题以及监控

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

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

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

一旦发现上面的二个情况的发生，我们可以采用的措施有以下几种：
1. 收紧内存。 在模块编写的时候，对于内存消费大户的模块，比如说cache等，注册接收内存紧张的信息。一旦收到此类威胁信号，马上释放掉不必要的内存，保命要紧。

2. 切断或者限制输入源，大部分的服务器程序都是网络服务，输入都是从用户的请求开始。 那我们可以暂时不接收或者减半处理用户的网络封包请求，使得工作进程能够及时处理滞留的消息。

3. 重新审视设计，为什么会有工作进程处理不过来的情况？是不是设计上服务有单点，能不能scale来处理。

这里重点看下如何发现内存紧张。Erts本事提供很多的信息源让用户来知道目前VM内部模块的内存使用情况，但是经常身在此山中，无法从更高的角度来看这个问题。

Erlang提供了memsup模块来让用户从操作系统的角度了解整个VM占用的VM情况。文档参看这里

memsup is a process which supervises the memory usage for the system and for individual processes. It is part of the OS_Mon application, see os_mon(6). Available for Unix, Windows and VxWorks.

Periodically performs a memory check:
*If more than a certain amount of available system memory is allocated, as reported by the underlying operating system, the alarm {system_memory_high_watermark, []} is set.
*If any Erlang process Pid in the system has allocated more than a certain amount of total system memory, the alarm {process_memory_high_watermark, Pid} is set.

通过预设内存使用的上限，当使用过度的时候，我们就可以收到这种报警消息，我们的应用就有了进一步处理的依据了。
这方面 rabbitmq 处理的非常好，所以rabbitmq很稳健，代码也写得很清爽，各位可以参考下。

祝玩得开心！

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: gen_tcp接受链接时enfile的问题分析及解决

最近我们为了安全方面的原因，在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代码：

static int sock_alloc_fd(struct file **filep)
{
        int fd;

        fd = get_unused_fd();
        if (likely(fd >= 0)) {
                struct file *file = get_empty_filp();

                *filep = file;
                if (unlikely(!file)) {
                        put_unused_fd(fd);
                        return -ENFILE;
                }
        } else
                *filep = NULL;
        return fd;
}

static int __sock_create(int family, int type, int protocol, struct socket **res, int kern)
{
...
/*
 *      Allocate the socket and allow the family to set things up. if
 *      the protocol is 0, the family is instructed to select an appropriate
 *      default.
 */

        if (!(sock = sock_alloc())) {
                if (net_ratelimit())
                        printk(KERN_WARNING "socket: no more sockets\n");
                err = -ENFILE;          /* Not exactly a match, but its the
                                           closest posix thing */
                goto out;
        }
...
}

asmlinkage long sys_accept(int fd, struct sockaddr __user *upeer_sockaddr, int __user *upeer_addrlen)
{
        struct socket *sock, *newsock;
        struct file *newfile;
        int err, len, newfd, fput_needed;
        char address[MAX_SOCK_ADDR];

        sock = sockfd_lookup_light(fd, &err, &fput_needed);
        if (!sock)
                goto out;

        err = -ENFILE;
        if (!(newsock = sock_alloc()))
                goto out_put;
...
}

从代码来看，会返回ENFILE都是由于socket句柄分配不出来了，我们还是本着怀疑的态度来写个stap脚本来再次验证下：

$ cat enfile.stp
probe kernel.function("kmem_cache_alloc").return,
          kernel.function("get_empty_filp").return{
  if($return == 0) { print_backtrace();exit();}
}
probe kernel.function("sock_alloc_fd").return {
  if($return < 0) { print_backtrace(); exit();}
}
probe syscall.accept.return {
  if($return == -23) {print_backtrace(); exit();}
}
probe begin {
println(":~");
}
$ sudo stap enfile.stp
:~

gen_tcp:accept报告{error, enfile}的时候，也没看到stap报异常，基本上可以排除操作系统的原因了，那么我们现在回到gen_tcp的实现来看。
gen_tcp是个port, 具体实现在erts/emulator/drivers/common/inet_drv.c，我们来看下有ENFILE的地方：

/* Copy a descriptor, by creating a new port with same settings
 * as the descriptor desc.
 * return NULL on error (ENFILE no ports avail)
 */
static tcp_descriptor* tcp_inet_copy(tcp_descriptor* desc,SOCKET s,
                                     ErlDrvTermData owner, int* err)
{
...
    /* The new port will be linked and connected to the original caller */
    port = driver_create_port(port, owner, "tcp_inet", (ErlDrvData) copy_desc);
    if ((long)port == -1) {
        *err = ENFILE;
        FREE(copy_desc);
        return NULL;
    }
...
}

当 driver_create_port 失败的时候，gen_tcp返回ENFILE,看起来这次找对地方了。我们继续看下 driver_create_port的实现：
看下erts/emulator/beam/io.c：

/*
 * Driver function to create new instances of a driver
 * Historical reason: to be used with inet_drv for creating
 * accept sockets inorder to avoid a global table.
 */
ErlDrvPort
driver_create_port(ErlDrvPort creator_port_ix, /* Creating port */
                   ErlDrvTermData pid,    /* Owner/Caller */
                   char* name,            /* Driver name */
                   ErlDrvData drv_data)   /* Driver data */
{
...
    rp = erts_pid2proc(NULL, 0, pid, ERTS_PROC_LOCK_LINK);
    if (!rp) {
        erts_smp_mtx_unlock(&erts_driver_list_lock);
        return (ErlDrvTermData) -1;   /* pid does not exist */
    }
    if ((port_num = get_free_port()) < 0) {
        errno = ENFILE;
        erts_smp_proc_unlock(rp, ERTS_PROC_LOCK_LINK);
        erts_smp_mtx_unlock(&erts_driver_list_lock);
        return (ErlDrvTermData) -1;
    }

    port_id = make_internal_port(port_num);
    port = &erts_port[port_num & erts_port_tab_index_mask];
...
}

get_free_port()<0的时候就返回ENFILE错误。
那我们看下port总的数目是如何设定的：

/* initialize the port array */
void init_io(void)
{
…
 if (erts_sys_getenv("ERL_MAX_PORTS", maxports, &maxportssize) == 0)
        erts_max_ports = atoi(maxports);
    else
        erts_max_ports = sys_max_files();

    if (erts_max_ports > ERTS_MAX_PORTS)
        erts_max_ports = ERTS_MAX_PORTS;
    if (erts_max_ports < 1024)
        erts_max_ports = 1024;

    if (erts_use_r9_pids_ports) {
        ports_bits = ERTS_R9_PORTS_BITS;
        if (erts_max_ports > ERTS_MAX_R9_PORTS)
            erts_max_ports = ERTS_MAX_R9_PORTS;
    }

    port_extra_shift = erts_fit_in_bits(erts_max_ports – 1);
    port_num_mask = (1 << ports_bits) – 1;
…
}

第一步：如果设定了ERL_MAX_PORTS环境变量，那么就按照用户设定的，否则就和ulimit -n 一样大。
第二部：这个值不能大于ERTS_MAX_PORTS或者小于1024.

好了，我们基本上明白这个问题的原因了： erts_max_ports设定的太小.

我们再来验证下：
gdb attach到我们的进程下
(gdb) p erts_max_ports
$1 = 4096
原来是port设置有问题，导致上面的现象，看起来很绕的，Erlang的设计者认为PORT资源（相当于操作系统的IO资源）短缺如同操作系统的文件句柄短缺一样，达到system_limit就应该出ENFILE错误！

解决方案是: erl -env ERTS_MAX_PORTS NNNN 搞大点就好。

顺便再来强调下Erlang服务器几个关键的参数，来源：http://www.ejabberd.im/tuning，对服务器的设置很有帮助。

This page lists several tricks to tune your ejabberd and Erlang installation for maximum performance gains. Remark that some of the described options are experimental.

Erlang Ports Limit: ERL_MAX_PORTS
Erlang consumes one port for every connection, either from a client or from another Jabber server. The option ERL_MAX_PORTS limits the number of concurrent connections and can be specified when starting ejabberd:

erl -s ejabberd -env ERL_MAX_PORTS 5000 ...

Maximum Number of Erlang Processes: +P
Erlang consumes a lot of lightweight processes. If there is a lot of activity on ejabberd so that the maximum number of proccesses is reached, people will experiment greater latency times. As these processes are implemented in Erlang, and therefore not related to the operating system processes, you do not have to worry about allowing a huge number of them.

erl -s ejabberd +P 250000 ...

ERL_FULLSWEEP_AFTER: Maximum number of collections before a forced fullsweep
The ERL_FULLSWEEP_AFTER option shrinks the size of the Erlang process after RAM intensive events. Note that this option may downgrade performance. Hence this option is only interesting on machines that host other services (webserver, mail) on which ejabberd does not receive constant load.

erl -s ejabberd -env ERL_FULLSWEEP_AFTER 0 ...

Kernel Polling: +K true

The kernel polling option requires that you have support for it in your kernel. By default, Erlang currently supports kernel polling under FreeBSD, Mac OS X, and Solaris. If you use Linux, check this newspost. Additionaly, you need to enable this feature while compiling Erlang.

From Erlang documentation -> Basic Applications -> erts -> erl -> System Flags:

+K true|false

Enables or disables the kernel poll functionality if the emulator has kernel poll support. By default the kernel poll; functionality is disabled. If the emulator doesn't have kernel poll support and the +K flag is passed to the emulator, a warning is issued at startup.

If you meet all requirements, you can enable it in this way:

erl -s ejabberd +K true ...

Mnesia Tables to Disk
By default, ejabberd uses Mnesia as its database. In Mnesia you can configure each table in the database to be stored on RAM, on RAM and on disk, or only on disk. You can configure this in the web interface: Nodes -> 'mynode' -> DB Management. Modification of this option will consume some memory and CPU time.
Number of Concurrent ETS and Mnesia Tables: ERL_MAX_ETS_TABLES
The number of concurrent ETS and Mnesia tables is limited. When the limit is reached, errors will appear in the logs:

** Too many db tables **

You can safely increase this limit when starting ejabberd. It impacts memory consumption but the difference will be quite small.

erl -s ejabberd -env ERL_MAX_ETS_TABLES 20000 ...

小结：很多问题是很绕的，要多方面考虑验证。

祝玩得开心！

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: 很容易忽略的ETS表个数限制问题

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

知道了问题的本质就很容易解决问题：
erl -env ERL_MAX_ETS_TABLES NNNNN就好了。

再来顺手看下ejabberd的配置文件的说明：

# ERL_MAX_ETS_TABLES: Maximum number of ETS and Mnesia tables
#
# The number of concurrent ETS and Mnesia tables is limited. When the limit is
# reached, errors will appear in the logs:
# ** Too many db tables **
# You can safely increase this limit when starting ejabberd. It impacts memory
# consumption but the difference will be quite small.
#
# Default: 1400
#
#ERL_MAX_ETS_TABLES=1400

但是如何知道N设成多大比较合适呢？

erl shell下按下CTRL+C 再按下i就告诉你现在这些核心资源包括ets的使用情况,具体见以下代码。 你一看用的差不多了，就搞大点。

void
info(int to, void *to_arg)
{
    erts_memory(&to, to_arg, NULL, THE_NON_VALUE);
    atom_info(to, to_arg);
    module_info(to, to_arg);
    export_info(to, to_arg);
    register_info(to, to_arg);
    erts_fun_info(to, to_arg);
    erts_node_table_info(to, to_arg);
    erts_dist_table_info(to, to_arg);
    erts_allocated_areas(&to, to_arg, NULL);
    erts_allocator_info(to, to_arg);
}

其实还有一个更简单的方法用crashdump viewer看下实际系统中有多少进程，每个进程消耗多少port和ets表。
我来说下大概的步骤：
1. 产生crashdump： 在实际运行的系统中按下CTRL+C再按大写的A，看到系统退出，生成我们系统运行期的快照。
2. 运行webtool: webtool:start() 他会告诉我们web地址,打开浏览器，打开该地址。
3. 在webtool中打开crashdump viewer模块，加载我们的crashdump文件进行分析，得到系统运行期的友好的解释。
4. 在进程这一栏里面可以看到每个进程的状态和使用的资源。

根据这些信息稍微估算下系统需要开多少process和port，提前规划好。

祝玩的开心！

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: Erlang open_port极度影响性能的因素

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实现的代码：

// sys.c:L1352
static ErlDrvData spawn_start(ErlDrvPort port_num, char* name, SysDriverOpts* opts)
{
...
#if !DISABLE_VFORK
    int no_vfork;
    size_t no_vfork_sz = sizeof(no_vfork);

    no_vfork = (erts_sys_getenv("ERL_NO_VFORK",
                                (char *) &no_vfork,
                                &no_vfork_sz) >= 0);
#endif
...
else { /* Use vfork() */
        char **cs_argv= erts_alloc(ERTS_ALC_T_TMP,(CS_ARGV_NO_OF_ARGS + 1)*
                                   sizeof(char *));
        char fd_close_range[44];                  /* 44 bytes are enough to  */
        char dup2_op[CS_ARGV_NO_OF_DUP2_OPS][44]; /* hold any "%d:%d" string */
                                                  /* on a 64-bit machine.    */

        /* Setup argv[] for the child setup program (implemented in
           erl_child_setup.c) */
        i = 0;
        if (opts->use_stdio) {
            if (opts->read_write & DO_READ){
                /* stdout for process */
                sprintf(&dup2_op[i++][0], "%d:%d", ifd[1], 1);
                if(opts->redir_stderr)
                    /* stderr for process */
                    sprintf(&dup2_op[i++][0], "%d:%d", ifd[1], 2);
            }
            if (opts->read_write & DO_WRITE)
                /* stdin for process */
                sprintf(&dup2_op[i++][0], "%d:%d", ofd[0], 0);
        } else {        /* XXX will fail if ofd[0] == 4 (unlikely..) */
            if (opts->read_write & DO_READ)
                sprintf(&dup2_op[i++][0], "%d:%d", ifd[1], 4);
            if (opts->read_write & DO_WRITE)
                sprintf(&dup2_op[i++][0], "%d:%d", ofd[0], 3);
        }
        for (; i < CS_ARGV_NO_OF_DUP2_OPS; i++)
            strcpy(&dup2_op[i][0], "-");
        sprintf(fd_close_range, "%d:%d", opts->use_stdio ? 3 : 5, max_files-1);

        cs_argv[CS_ARGV_PROGNAME_IX] = child_setup_prog;
        cs_argv[CS_ARGV_WD_IX] = opts->wd ? opts->wd : ".";
        cs_argv[CS_ARGV_UNBIND_IX] = erts_sched_bind_atvfork_child(unbind);
        cs_argv[CS_ARGV_FD_CR_IX] = fd_close_range;
        for (i = 0; i < CS_ARGV_NO_OF_DUP2_OPS; i++)
            cs_argv[CS_ARGV_DUP2_OP_IX(i)] = &dup2_op[i][0];
        if (opts->spawn_type == ERTS_SPAWN_EXECUTABLE) {
            int num = 0;
            int j = 0;
            if (opts->argv != NULL) {
                for(; opts->argv[num] != NULL; ++num)
                    ;
            }
            cs_argv = erts_realloc(ERTS_ALC_T_TMP,cs_argv, (CS_ARGV_NO_OF_ARGS + 1 + num + 1) * sizeof(char *));
            cs_argv[CS_ARGV_CMD_IX] = "-";
            cs_argv[CS_ARGV_NO_OF_ARGS] = cmd_line;
            if (opts->argv != NULL) {
                for (;opts->argv[j] != NULL; ++j) {
                    if (opts->argv[j] == erts_default_arg0) {
                        cs_argv[CS_ARGV_NO_OF_ARGS + 1 + j] = cmd_line;
                    } else {
                        cs_argv[CS_ARGV_NO_OF_ARGS + 1 + j] = opts->argv[j];
                    }
                }
            }
            cs_argv[CS_ARGV_NO_OF_ARGS + 1 + j] = NULL;
        } else {
            cs_argv[CS_ARGV_CMD_IX] = cmd_line; /* Command */
            cs_argv[CS_ARGV_NO_OF_ARGS] = NULL;
        }
        DEBUGF(("Using vfork\n"));
        pid = vfork();

	if (pid == 0) {
	    /* The child! */

	    /* Observe!
             * OTP-4389: The child setup program (implemented in
             * erl_child_setup.c) will perform the necessary setup of the
             * child before it execs to the user program. This because
             * vfork() only allow an *immediate* execve() or _exit() in the
             * child.
             */
            execve(child_setup_prog, cs_argv, new_environ);
	    _exit(1);
        }
        erts_free(ERTS_ALC_T_TMP,cs_argv);
...
}

在支持vfork的系统下，比如说linux，除非禁止，默认会采用vfork来执行child_setup来调用外部程序。
看下vfork的文档：

vfork() differs from fork() in that the parent is suspended until the child makes a call to execve(2) or _exit(2). The child shares all memory
with its parent, including the stack, until execve() is issued by the child. The child must not return from the current function or call
exit(), but may call _exit().

vfork的时候beam.smp整个进程会被阻塞，所以这里是个很重要的性能影响点。

我们再看下erl_child_setup.c的代码：

// erl_child_setup.c:111
// 1.  取消绑定
if (strcmp("false", argv[CS_ARGV_UNBIND_IX]) != 0)
	if (erts_unbind_from_cpu_str(argv[CS_ARGV_UNBIND_IX]) != 0)
            return 1;
// 2.  复制句柄
 for (i = 0; i < CS_ARGV_NO_OF_DUP2_OPS; i++) {
        if (argv[CS_ARGV_DUP2_OP_IX(i)][0] == '-'
            && argv[CS_ARGV_DUP2_OP_IX(i)][1] == '\0')
            break;
        if (sscanf(argv[CS_ARGV_DUP2_OP_IX(i)], "%d:%d", &from, &to) != 2)
            return 1;
        if (dup2(from, to) < 0)
            return 1;
    }
// 3. 关闭句柄
if (sscanf(argv[CS_ARGV_FD_CR_IX], "%d:%d", &from, &to) != 2)
        return 1;
    for (i = from; i <= to; i++)
        (void) close(i);

// 4. 调用外部程序
if (erts_spawn_executable) {
        if (argv[CS_ARGV_NO_OF_ARGS + 1] == NULL) {
            execl(argv[CS_ARGV_NO_OF_ARGS],argv[CS_ARGV_NO_OF_ARGS],
                  (char *) NULL);
        } else {
            execv(argv[CS_ARGV_NO_OF_ARGS],&(argv[CS_ARGV_NO_OF_ARGS + 1]));
        }
    } else {
        execl("/bin/sh", "sh", "-c", argv[CS_ARGV_CMD_IX], (char *) NULL);
    }
...

这是一个非常流程多的过程，而且1，2，3这三个步骤都非常的耗时。 特别是3对于一个繁忙的IO服务器来讲，会打开大量的句柄，可能都有几十万，关闭这么多的句柄会是个灾难。

我们来演习下这个流程和具体的性能数字：
首先我们设计个open_port的场景，服务器打开768个socke句柄，再运行cat外部程序。

$ cat demo.erl
-module(demo).
-compile(export_all).

start()->
    _ = [gen_udp:open(0) || _ <- lists:seq(1,768)],
    Port = open_port({spawn, "/bin/cat"}, [in, out, {line, 128}]),
    port_close(Port),
    ok.

我们再准备个stap脚本，用来分析这些行为和性能数字：

$ cat demo.stp
global t0, t1, t2

probe process("beam.smp").function("spawn_start") {
        printf("spawn %\s\n", user_string($name))
        t0 = gettimeofday_us()
}

probe process("beam.smp").statement("*@sys.c:1607") {
        t1 = gettimeofday_ns()
}

probe process("beam.smp").statement("*@sys.c:1627") {
        printf("vfork take %d ns\n", gettimeofday_ns() - t1);
}

probe process("child_setup").function("main") {
        t2 = gettimeofday_us()
}

probe process("child_setup").statement("*@erl_child_setup.c:111") {
        t3 = gettimeofday_us()
        printf("spawn take %d us, child_setup take %d us\n", t3 - t0, t3 - t2)
}

probe syscall.execve {
        printf("%s, arg %s\n", name, argstr)
}

probe syscall.fork {
        printf("%s, arg %s\n", name, argstr)
}

probe begin {
        println(")");

我们在一个终端下运行stap脚本观察行为：

$ erlc demo.erl
$ PATH=otp/bin/x86_64-unknown-linux-gnu/:$PATH sudo stap demo.stp
)
fork, arg
execve, arg otp/bin/erl
fork, arg
fork, arg
fork, arg
execve, arg /bin/sed "s/.*\\///"
execve, arg /home/chuba/otp/bin/x86_64-unknown-linux-gnu/erlexec
execve, arg /home/chuba/otp/bin/x86_64-unknown-linux-gnu/beam.smp "--" "-root" "/home/chuba/otp" "-progname" "erl" "--" "-home" "/home/chuba" "--"
clone, arg .
..
clone, arg CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID
spawn inet_gethost 4
fork, arg
execve, arg /home/chuba/otp/bin/x86_64-unknown-linux-gnu/child_setup "FFFF" "." "exec inet_gethost 4 " "3:327679" "8:1" "9:0" "-"
vfork take 8487 ns
spawn take 173707 us, child_setup take 94535 us
execve, arg /bin/sh "-c" "exec inet_gethost 4 "
execve, arg /home/chuba/otp/bin/x86_64-unknown-linux-gnu/inet_gethost "4"
fork, arg
clone, arg CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID
clone, arg CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID
spawn /bin/cat
fork, arg
execve, arg /home/chuba/otp/bin/x86_64-unknown-linux-gnu/child_setup "FFFF" "." "exec /bin/cat" "3:327679" "2312:1" "2313:0" "-"
vfork take 5298 ns
spawn take 180974 us, child_setup take 101646 us
execve, arg /bin/sh "-c" "exec /bin/cat"
execve, arg /bin/cat
spawn /bin/cat
fork, arg
execve, arg /home/chuba/otp/bin/x86_64-unknown-linux-gnu/child_setup "FFFF" "." "exec /bin/cat" "3:327679" "3080:1" "3081:0" "-"
vfork take 8929 ns
spawn take 169569 us, child_setup take 90163 us
execve, arg /bin/sh "-c" "exec /bin/cat"
execve, arg /bin/cat
...

在另外一个终端下运行我们的测试案例：

$ otp/bin/erl
Erlang R14B04 (erts-5.8.5) 1[/source] [64-bit] [smp:16:16] [rq:16] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.8.5  (abort with ^G)
1> demo:start().
ok
2> demo:start().
ok
3>

我们可以看到二次执行的开销差不多：
vfork take 8929 ns
spawn take 169569 us, child_setup take 90163 us

从实验得来的数字来看：
vfork需要阻塞beam.smp 8个us时间，而整个spawn下来要169ms, 其中 child_setup关闭句柄等等花了90ms， 数字无情的告诉我们这些性能杀手不容忽视。

解决方案：
1. 改用fork避免阻塞beam.smp, erl -env ERL_NO_VFORK 1
2. 减少文件句柄,如果确实需要大量的open_port让另外一个专注的节点来做。

祝玩得开心!

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: Erlang R15的内存delayed dealloc特性对消息密集型程序的影响

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

我们来尝鲜演示下，首先设计个消息密集型的程序：

抱歉由于刚才的POST测试案例设计不合理，重新设计过,敬请期待。。。

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: Linux下pipe使用注意事项

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

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

//pipe.c:L349
static ssize_t
pipe_read(struct kiocb *iocb, const struct iovec *_iov,
               unsigned long nr_segs, loff_t pos)
{
...
   if (ret > 0)
        file_accessed(filp);
    return ret;
}

我们可以看到在pipe读的时候要设置 file_accessed时间的,接着:

//fs.h:L1761
extern void touch_atime(struct vfsmount *mnt, struct dentry *dentry);
static inline void file_accessed(struct file *file)
{
        if (!(file->f_flags & O_NOATIME))
                touch_atime(file->f_path.mnt, file->f_path.dentry);
}

如果文件没设置 O_NOATIME就真正动手设置atime,接着:

//inode.c:L1493
void touch_atime(struct vfsmount *mnt, struct dentry *dentry)
{
        struct inode *inode = dentry->d_inode;
        struct timespec now;

        if (inode->i_flags & S_NOATIME)
                return;
        if (IS_NOATIME(inode))
                return;
        if ((inode->i_sb->s_flags & MS_NODIRATIME) && S_ISDIR(inode->i_mode))
                return;

        if (mnt->mnt_flags & MNT_NOATIME)
                return;
        if ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode))
                return;

        now = current_fs_time(inode->i_sb);

        if (!relatime_need_update(mnt, inode, now))
                return;

        if (timespec_equal(&inode->i_atime, &now))
                return;

        if (mnt_want_write(mnt))
                return;

        inode->i_atime = now;
        mark_inode_dirty_sync(inode);
        mnt_drop_write(mnt);
}

我们可以看出上面的流程还是比较复杂的,开销也很大.
我们来演示下:

$ cat > pipe_test.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <assert.h>
#include <pthread.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <linux/unistd.h>

static int fds[2];
static pthread_t rp;

static void *rp_entry(void *arg) {
  char c[1];
  while (1 == read(fds[0], c, 1)) {
    if (*c == 'Q') break;
  }
  fprintf(stderr, "pipe read ok\n");
  return NULL;
}

int main(int argc, char *argv[]) {
  long i, n;
  int rc;
  if (argc < 2) {
    fprintf(stderr, "usage: pipe_test NNNNNN\n");
    return -1;
  }
  n = atol(argv[1]);
  pipe(fds);
  //fcntl(fds[0], F_SETFL, O_NOATIME);
  pthread_create(&rp, NULL, rp_entry, NULL);
  fprintf(stderr, "pipe write %ld...", n);
  for (i = 0; i < n; i++) {
    write(fds[1], "A", 1);
  }
  write(fds[1], "Q", 1);
  fprintf(stderr, "ok\n");
  pthread_join(rp, NULL);
  close(fds[0]);
  close(fds[1]);
  return 0;
}
CTRL+D
$ gcc -D_GNU_SOURCE pipe_test.c -lpthread
$ sudo opcontrol --setup --vmlinux=/usr/lib/debug/lib/modules/2.6.18-164.el5/vmlinux
$ sudo opcontrol --init && sudo opcontrol --reset && sudo opcontrol --start
$ ./a.out 10000000
pipe write 10000000...ok
pipe read ok
$ sudo opcontrol --shutdown
$ opreport -l|less
samples  %        app name                 symbol name
378654   92.7742  vmlinux                  .text.acpi_processor_idle
12978     3.1797  vmlinux                  current_fs_time
2530      0.6199  vmlinux                  thread_return
2345      0.5745  vmlinux                  touch_atime
2253      0.5520  vmlinux                  .text.acpi_safe_halt
1597      0.3913  vmlinux                  timespec_trunc
1368      0.3352  vmlinux                  file_update_time
1253      0.3070  vmlinux                  __mark_inode_dirty
901       0.2208  vmlinux                  pipe_writev
768       0.1882  vmlinux                  __mutex_lock_slowpath
763       0.1869  vmlinux                  try_to_wake_up
270       0.0662  vmlinux                  copy_user_generic_unrolled
254       0.0622  vmlinux                  acpi_set_register
254       0.0622  vmlinux                  system_call
233       0.0571  vmlinux                  pipe_readv
188       0.0461  vmlinux                  dnotify_parent
167       0.0409  vmlinux                  mutex_unlock
...

我们可以看到touch_atime的开销很大,远比pipe的读写大.
这次把这行注释去掉: fcntl(fds[0], F_SETFL, O_NOATIME); 指示pipe在读的时候不更新atime,看下效果:

$ opreport -l|less
samples  %        app name                 symbol name
599018   95.2466  vmlinux                  .text.acpi_processor_idle
4140      0.6583  vmlinux                  .text.acpi_safe_halt
3281      0.5217  vmlinux                  thread_return
2812      0.4471  vmlinux                  current_fs_time
2615      0.4158  vmlinux                  file_update_time
1790      0.2846  vmlinux                  __mutex_lock_slowpath
1657      0.2635  vmlinux                  timespec_trunc
1341      0.2132  vmlinux                  try_to_wake_up
1281      0.2037  vmlinux                  mutex_unlock
1080      0.1717  vmlinux                  mutex_lock
1001      0.1592  vmlinux                  pipe_readv
925       0.1471  vmlinux                  pipe_writev

这下看不到touch_atime了,开销省了,对于高性能服务器是很重要的.
小结: 细节很重要,记得开文件open的时候设置O_NOATIME或者用fcntl搞定它.
祝玩得开心!

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: Erlang版TCP服务器对抗攻击解决方案

互联网上的TCP服务器面对的环境情况比企业私有的服务器要复杂很多。常见的针对tcp服务器的攻击有以下几种：
1. 伪造协议，导致服务器crash. 比如说某条命令的字段长度，协议最大规定是1024，伪造个4096的。
2. 伪造大的报文。比如说一个包有1024M这么大。
3. 消耗服务器资源。开大量的连接， 以龟速发送报文，比如说每分钟一个字节。
4. DDOS攻击，从不同的IP发起大量的连接。
5. 攻击Erlang集群的授权体系。
6. 报文发送顺序逻辑错误，导致服务器crash. 比如说逻辑上应该先发A，再发B, 攻击者调了顺序。
7. 不停的连接断开，消耗服务器对资源的申请和释放，这个通常很耗。
等等，有很多方法。

那我们的Erlang版的TCP服务器如何应对这些情况呢？

刚才不小心按了发布，待续。。。

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: 简单的Map reduce用的收集函数

在处理大量重复任务的时候，为了加快速度，通常会用map-reduce的方式，要是能有段代码做这个事情就好了。作者luke写了底下的代码片段，用起来感觉挺爽的，推荐给大家。原文见这里

%% http://lukego.livejournal.com/6753.html – that doesn’t care about
%% the order in which results are received.
upmap(F, L) ->
Parent = self(),
Ref = make_ref(),
[receive {Ref, Result} -> Result end
|| _ <- [spawn(fun() -> Parent ! {Ref, F(X)} end) || X <- L]].

这个函数的特点是不依赖于任务完成的顺序，结构很简单优雅。

祝玩得开心！

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: 看multitrace代码学习如何定制自己的dbg信息

multitrace是ttb应用带的一个例子，给了个例子让用户来格式化和定制自己的dbg信息。 文档在这里：

The module multitrace.erl which can be found in the src directory of the Observer application implements a small tool with three possible trace settings. The trace messages are written to binary files which can be formatted with the function multitrace:format/1/2.

代码太长，我就不贴了，可以点这里查看.

我演示下如何使用：

$ pwd
/home/chuba/otp/lib/observer/src
$ erlc multitrace.erl
$ erl
Erlang R14B04 (erts-5.8.5) 1 [64-bit] [smp:16:16] [rq:16] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.8.5  (abort with ^G)
1> multitrace:schedule(self()).
ok
2> erlang:ports().
[#Port<0.1>,#Port<0.49>,#Port<0.406>,#Port<0.415>,
 #Port<0.714>,#Port<0.720>]
3> multitrace:stop().
stopped
4> multitrace:format("nonode@nohost-schedule_trace").

Tracing started on node nonode@nohost at 2011-10-27 16:29:40,984702
Flags: [{[<0.47.0>],[running,timestamp]}]

in:
Process  : <0.47.0>
Time     : 2011-10-27 16:29:40,984453
Function : {dbg,req,1}

out:
Process  : <0.47.0>
Time     : 2011-10-27 16:29:40,984528
Function : {io,wait_io_mon_reply,2}

in:
Process  : <0.47.0>
Time     : 2011-10-27 16:29:40,984582
Function : {io,wait_io_mon_reply,2}

out:
Process  : <0.47.0>
Time     : 2011-10-27 16:29:40,984635
Function : {io,wait_io_mon_reply,2}

in:
Process  : <0.47.0>
Time     : 2011-10-27 16:29:40,984662
Function : {io,wait_io_mon_reply,2}

out:
Process  : <0.47.0>
Time     : 2011-10-27 16:29:40,984720
Function : {shell,eval_loop,3}

in:
Process  : <0.47.0>
Time     : 2011-10-27 16:30:32,215798
Function : {shell,eval_loop,3}

out:
Process  : <0.47.0>
Time     : 2011-10-27 16:30:32,216096
Function : {code_server,call,2}

in:
Process  : <0.47.0>
Time     : 2011-10-27 16:30:32,216155
Function : {code_server,call,2}

Total time 'in' for process <0.47.0>: 484 micro seconds
ok
13>

我们可以在自己的项目里面结合ttb做些调试模块，方便在出现问题的时候定位问题。

祝玩得开心！