系统技术非业余研究

这个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…

在做系统调优或者调查性能问题的的时候，比如说调查一个锁的性能问题。 这把锁的代码会有很多路径会调用， 我们可以在锁的地方设个probe点，但是我们无法知道那个路径是最经常调用的。 所以我就写了个stap脚本来解决这个问题，代码在RHEL 5.4/6下都调试没有问题的。

$ cat  > dig.stp 
global stacks_count

probe process(@1).function(@2)
{
 stacks_count[ubacktrace()]++;
}

function sprint_stackx(stack)
{
addr = tokenize(stack, " ");
while(addr != "")
{
        fun= symname(strtol(addr, 16));
        s = fun . "->" . s;
        addr = tokenize("", " ");
}
return s;
}

function print_top_stack () {
  printf ("%50s %10s\n", "STACK", "COUNT")
  foreach (stack in stacks_count- limit 20) {
    printf("%50s %10d\n", sprint_stackx(stack), stacks_count[stack])
  }
  delete stacks_count
}

probe timer.s(5) {
  print_top_stack ()
  printf("--------------------------------------------------------------\n")
}

CTRL+D

#我们用nmon这个程序来试验下吧
#脚本的使用方法是: stap dig.stp prog funcs
#注意这个程序需要-g编译， 才能有符号信息

#在另外一个控制台下运行nmon, 打开磁盘，CPU监控等。
$nmon

$ sudo stap dig.stp nmon proc_*
                                             STACK      COUNT
                                 main->proc_read->          2
                                  main->proc_cpu->          2
                                 main->proc_read->          2
                                  main->proc_mem->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
--------------------------------------------------------------
...

哈效果不错哦！

祝玩的开心。

通常我们在做内核编程的时候，会用到内核的数据结构，比如说textsearch提供了几种算法用于支付串查找。在用于正式的项目前，我们会希望考察下他的用法以及想体验下。最通常的做法是自己写个module,写个makefile,编译，运行，然后去dmesg里面看printk的结果。这个过程没啥问题，就是太罗嗦。好了，现在我们有更方便的方法了：systemtap.

Systemtap是个脚本，先翻译成c kernel模块代码，然后编译，插入到内核运行，同时提供最基本的内核和应用模块的通讯管道，在应用模块这里收集信息。 它还支持guru模式，让用户直接插入c代码。 这样我们就可以利用stap的这一特性来做我们的实验。
Read more…

参考文章：
1. https://groups.google.com/group/erlang-programming/msg/2d61b1083a10a7b6

2. http://erlang.2086793.n4.nabble.com/How-to-Cross-compile-Erlang-OTP-R13B04-for-TileraPro64-td2119304.html

美国Tilera公司的众核服务器，单颗内核包含64颗CPU。硬件架构图：

卡长这样的：

Erlang已经可以在这款CPU上成功运行，我们可以参考Ulf Wiger在Multicore ☺ Message-passing Concurrency 文档中关于Erlang在Tilera上的性能图.

Erlang系统前2年就开始正式支持Tilera，一直用这个CPU来调整他的调度器，所以性能和基础的编译运行支持都很到位。

Linux内核2.6.36起就开始支持Tilera的CPU架构了，看起来前途不错。

最近 上海泛腾电子科技 开始在国内销售 Tilera机器， 我公司也得到一台样机，使得我有机会把玩下这个高科技！

该测试机是PCI-e的形式，是单板机，直接安装在PC机或者是服务器里,好处是可以通过主机的VGA口接显示器直接调试。当然也可以作为智能网卡来使用。构成一个与Host的异构结构，通过PCI-e总线进行通讯。

还需要相应的配套SDK: 目前有TileraMDE-2.1.2.112814 和 TileraMDE-3.0.alpha3.116173 二个版本, 来负责和板卡的通信。 推荐用2.0的，好像不容易出问题。

废话少说，让我们开始享受64核心快乐旅程吧！
Read more…

在做多线程程序的时候,为了避免使用锁,我们通常会采用这样的数据结构:根据线程的数目,安排一个数组, 每个线程一个项,互相不冲突. 从逻辑上看这样的设计无懈可击,但是实践的过程我们会发现这样并没有提高速度. 问题在于cpu的cache line. 我们在读主存的时候,数据同时被读到L1,L2中去,而且在L1中是以cache line(通常64)字节为单位的. 每个Core都有自己的L1,L2,所以每个线程在读取自己的项的时候, 也把别人的项读进去, 所以在更新的时候,为了保持数据的一致性, core之间cache要进行同步, 这个会导致严重的性能问题. 这就是所谓的False sharing问题, 有兴趣的同学可以wiki下.

具体的参考文章: http://software.intel.com/en-us/articles/avoiding-and-identifying-false-sharing-among-threads/

解决方法很简单:
把每个项凑齐cache line的长度,实现隔离.

typedef union {
    erts_smp_rwmtx_t rwmtx;
    byte cache_line_align__[ERTS_ALC_CACHE_LINE_ALIGN_SIZE(
				sizeof(erts_smp_rwmtx_t))];
} erts_meta_main_tab_lock_t;
或者 
_declspec (align(64)) int thread1_global_variable;
__declspec (align(64)) int thread2_global_variable;

这就是为什么在高性能服务器中到处看到cache_line_align, 号称是避免cache的trash.

类似valgrind和intel vtune的工具可以做这个层次的性能微调.