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
--------------------------------------------------------------
...
哈效果不错哦!
祝玩的开心。
Recent Comments