系统技术非业余研究

Linux下有时候我们需要知道一个进程在做什么，比如说程序不正常的时候，他到底在干吗？最直接的方法就是打印出他所有线程的调用栈，这样我们从栈再配合程序代码就知道程序在干吗了。
Linux下这个工具叫做pstack. 使用方法是

# pstack
Usage: pstack <process-id>

当然这个被调查的程序需要有符号信息。 比较雷人的是 这个程序竟然是个shell脚本，核心实现是gdb的 thread apply all bt， 我们可以观摩下他的实现，这个我们做类似的程序提供了一个很好的思路：
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…

在做系统调优或者调查性能问题的的时候，比如说调查一个锁的性能问题。 这把锁的代码会有很多路径会调用， 我们可以在锁的地方设个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
--------------------------------------------------------------
...

哈效果不错哦！

祝玩的开心。