系统技术非业余研究

最近关于Erlang程序在异常打印堆栈时候带上行号信息的提案开始被讨论了，具体看这里：
EEP 36: Line numbers in exceptions: http://www.erlang.org/eeps/eep-0036.html

初学Erlang的人估计都有这个困惑，程序异常的时候打印堆栈不假，但是只打出函数名，如果模块很长的话，很难找到具体发生异常的点，通常再通过打日志的方式来定位，非常的低效无聊。有人开玩笑说是Erlang鼓励写短函数和模块. 我曾经想了个方法解决这个问题, 见 这里 ， 但不是完美的方案。

EEP 36则是从编译器直接搞定这个问题，会爽很多, 我们看下他的效果：
Read more…

NIF是什么? A NIF library contains native implementation of some functions of an Erlang module.
不清楚的同学请参考http://www.erlang.org/doc/man/erl_nif.html.
这个功能对于扩展Erlang,利用现有的遗留c的财产,提高性能非常有帮助.
但是通常同学们会无视手册里面的一句话:

Avoid doing lengthy work in NIF calls as that may degrade the responsiveness of the VM. NIFs are called directly by the same scheduler thread that executed the calling Erlang code. The calling scheduler will thus be blocked from doing any other work until the NIF returns

导致了非常严重的设计问题. 比如在NIF里面调用mysql client api, 作费时的IO操作等等, 我已经看到好几个同学这么干了,为了揭示这个问题的严重性, davisp同学为我们写了个例子来演示这个问题: 代码在这里
https://github.com/davisp/sleepy.

Sleepy – A misbehaving NIF
This demonstrates what happens if a NIF takes a long time and is called from as many schedulers as exist in the VM. Namely, that the VM is halted until the NIF functions return.

我们来演示下把:
Read more…

即将发布的R14B01要支持ets的压缩，更大程度的提高内存的利用率。
在github上可以看到这个分支，有兴趣的同学可以下载下来看看。

压缩的时候只压缩value, key是不压缩的。 value特别简单类型的eterm也是不压缩的，因为zip压缩需要一定长度的内容，而且压缩本身也要加入一点的overload.

以下是sverker (author)的提交log.

ETS ‘compressed’ option.

The compressed format is using a slighty modified variant of the extern format
(term_to_binary). To not worsen key lookup’s too much, the top tuple itself
and the key element are not compressed. Table objects with only immediate
non-key elements will therefor not gain anything (but actually consume one
extra word for “alloc_size”).

我们来试验下吧：
Read more…

在EUC-2010上rickard做了个报告，详细的解读了R14B读写锁优化的有效性，并且给出了benchmark, 详见这里 http://www.erlang.org/~rickard/euc-2010/。

优化的效果非常好，读写锁比NPTL内置的有好几倍的提升，我也来体验下。

我的测试是在Dell R815机器上测试的，以下是它的硬件配置.
获取的系统信息脚本这里下载。

# summary.sh
      Date | 2010-11-25 14:18:18 UTC (local TZ: CST +0800)
    Hostname | =i
      Uptime |  9:02,  7 users,  load average: 10.27, 15.74, 11.78
      System | Dell Inc.; PowerEdge R815; vNot Specified (<OUT OF SPEC>)
 Service Tag | 55SSW2X
     Release | Red Hat Enterprise Linux Server release 5.4 (Tikanga)
      Kernel | 2.6.18-164.el5
Architecture | CPU = 64-bit, OS = 64-bit
   Threading | NPTL 2.5
    Compiler | GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-44).
     SELinux | Disabled
# Processor ##################################################
  Processors | physical = 4, cores = 48, virtual = 48, hyperthreading = no
      Speeds | 48x1900.026
      Models | 48xAMD Opteron(tm) Processor 6168
      Caches | 48x512 KB
# Memory #####################################################
       Total | 62.92G
        Free | 57.33G
        Used | physical = 5.60G, swap = 420.00k, virtual = 5.60G
     Buffers | 100.19M
      Caches | 186.92M
        Used | 5.20G
  Swappiness | vm.swappiness = 0
 DirtyPolicy | vm.dirty_ratio = 40, vm.dirty_background_ratio = 10
...

详细的请查看Dell R815机器配置

我的测试是这样的：
Read more…

刚刚结束的Erlang factory会议， Kenneth Lundin按照规矩汇报了下Erlang下一阶段的工作：

请参考： Latest News From the Erlang/OTP team at Ericsson
http://www.erlang-factory.com/upload/presentations/307/OTP_LATEST_NEWS_EUC10.pdf

这次的汇报很让人失望，除了回顾了下R14添加的读写锁的性能， 再有就是R14B01会支持ets的压缩，其他的都没有提到。 特别是上次承偌的numa和每调度器一个内存池的实现都没有提到。

随着硬件的发展，numa的问题越来越凸显。 我昨天测试的Dell 48核心/48G内存的机器，有8个numa node, 在一个进程用到很少内存的时候，系统开始swap, 但是实际上系统还有40G左右的内存。 而且在访问其他node的内存的时候，带宽从6G跌为4G，损失40%的性能。

期待otp团队给力！

这个MySQL服务器压测的需求是 ：

环境: Linux RHEL 5U4 X86-64, 24G内存， 16核.
MySQL服务器在xx.232.36.1上。

压力由最多32个客户端发起，每个客户端分别做update， insert, delete操作，概率分别是50%, 30%, 20%, 每种操作循环999999 × 100次，每100次操作后休息1-3秒。
这样的压力最多持续2个小时。

我们用的是著名的tsung压力测试工具， 之前我有篇blog介绍过， 见这里。

以下是用到的脚本， 用到了比较先进的随机动态参数替换等技术，对于编写此类脚本有很大的借鉴意义。
Read more…