IT牛人博客聚合

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

本文链接地址: Erlang虚拟机基础设施dtrace探测点介绍和使用

最新的Erlang虚拟机（R15B01）很大的一个改进就是加入了对dtrace探测点的支持了， 具体参见这里, 主要目标是方便在生产实践中定位复杂的性能问题。

目前Erlang的虚拟机的探测点支持Linux的systemtap和freebsd的dtrace，我们刚好能够享受的到。

作者Scott Lystig Fritchie在去年的euc中做了个很有意思的报告，参见这里，该PPT很详细的介绍了利用dtrace的探测点可以观察到erlang的行为如下：

Processes: spawn, exit,

查看全文: http://www.udpwork.com/item/7194.html

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

本文链接地址: MYSQL数据库网卡软中断不平衡问题及解决方案

最近公司在MySQL的数据库上由于采用了高速的如PCIe卡以及大内存，去年在压力测试的时候突然发现数据库的流量可以把一个千M网卡压满了。随着数据库的优化，现在流量可以达到150M，所以我们采用了双网卡，在交换机上绑定，做LB的方式，提高系统的吞吐量。

但是在最近压测试的一个数据库中，mpstat发现其中一个核的CPU被软中断耗尽：

Mysql QPS 2W左右

——– —–load-avg—- —cpu-usageR

查看全文: http://www.udpwork.com/item/6712.html

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

本文链接地址: systemtap如何跟踪libc.so

下午和周忱同学折腾复杂程序的内存泄漏问题，用了valgrind, gogle perftools等工具都不大好用，很容易把应用程序搞死，于是打算用systemtap来在libc.so层面了解内存的使用情况。主要思路就是看malloc/realloc和free的调用次数的平衡。

首先准备下环境，系统是标准的RHEL 5u4：

$ uname -r
2.6.18-164.el5

$ stap -V
SystemTap translator/driver (version 1.3/0.137 non-git sourc

查看全文: http://www.udpwork.com/item/6691.html

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

本文链接地址: 大文件重定向和管道的效率对比

微博上的@拉风_zhang提出了个问题：

@淘宝褚霸 请教个问题，#1. cat huge_dump.sql | mysql -uroot ；#2. mysql -uroot < huge_dump.sql ；#1效率要高，在linux中通过管道传输 和 < 这种方式有什么差别呢？谢谢！#AskBaye#

这个问题挺有意思的，我的第一反应是：

没比较过，应该是一样的，一个是cat负责打开文件，一个是bash

这种场景在MySQL运维操作里面应该比较多，所以就花了点时间做了个比较和原理上的分析：

我们先构造场景：

查看全文: http://www.udpwork.com/item/6558.html

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

本文链接地址: 调研内核调用栈方便的工具 kmalloc-top

我们在研究内核的时候，看了内核代码后，就想着某个函数被谁谁调用。 调用路径有很多条，有热门的，有偏门的，但从代码不大容易看出。 如果我们能和gdb那样在函数上设个断点，看下内核函数的调用栈就清楚了。 但是如何统计热门路线呢？用systemtap就可以，参看这里， 这里。

但是用systemtap写统计的时候，用到统计功能的话，如果你的采样点非常多，超过systemtap规定的上线，systemtap会选择罢工，直接推出，很不爽。

kmalloc-top就是为了解决这个问题写的一个perl脚本，原本用来调查

查看全文: http://www.udpwork.com/item/6522.html

原创文章，转载请注明： 转载自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 de

查看全文: http://www.udpwork.com/item/6466.html

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

本文链接地址: Linux高速缓存使用率调查

Linux的高速缓存pagecache对性能的影响至关重要，但是实际系统中我们的利用率如何呢，特别是具体到每个设备的利用情况。

从下图我们可以很清楚的看到：

我们知道IO请求由vfs发起，经过pagecache缓存，挡不住的就落实到io设备去，那么统计这个利用率就很简单。 我们只要知道挡不住的IO的比例就好了。

我写了个systemtap脚本来解决这个问题：

$ uname -r
2.6.18-164.el5

$ sudo rpm -i kernel-debuginfo-common-2.6.18-164.el5.x86

查看全文: http://www.udpwork.com/item/5150.html

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

本文链接地址: Linux文件预读分析以及评估对系统的影响

Linux系统很重要的一个性能提升点就是它的Pagecache， 因为内存比IO快太多了，所以大家都想进办法来利用这个cache。 文件系统也不例外，为了达到高性能，文件读取通常采用预读来预测用户的行为，把用户可能需要的数据预先读取到cache去，达到高性能的目的。

Linux各个发行版readahead的实现差异很大，我们这里重点讨论2.6.18, RHEL 5U4发行版的行为.文件预读的实现主要在mm/readahead.c中，代码才603行。 预读的流程大概是这样的，用户需要文件页面的时候入口函数do_gen

查看全文: http://www.udpwork.com/item/5145.html

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

本文链接地址: disktop per设备per应用层面的IO读写统计

我们在调优IO 密集型的应用是通常需要知道IO的使用情况. 但是iostat只能知道系统全局的,iotop只能知道每个应用的, 我们有时候需要细化到每个应用对每个设备的使用情况. 比如说mysql数据库我们通常把日志和数据分开到不同的设备, 那我们需要知道数据读写多少,日志读写多少,分开的了解.

目前还没有工具能够很轻松的了解. 幸运的是systemtap自己带的disktop可以帮我们做到,位于/usr/share/doc/systemtap/examples/io/disktop.stp.

我们先

查看全文: http://www.udpwork.com/item/5054.html

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

本文链接地址: Linux下方便的socket读写查看器（socktop）

晚上 雕梁 说要找个工具来调查下unix域套接字的发送和接受情况，比如说A程序是否送出，B程序是否接收到，他找了tcpdump ,wireshark什么的，貌似都不支持。

这时候还是伟大的systemtap来救助了。 因为所有的socket通讯都是通过socket接口来的，任何family的通讯包括unix域套接都要走的，所以只要截获了socket 读写的几个syscall 就搞定了.

systemtap发行版本提供了个工具socktop， 位于 /usr/share/doc/systemtap

查看全文: http://www.udpwork.com/item/4699.html

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

本文链接地址: latencytop深度了解你的Linux系统的延迟

我们在系统调优或者定位问题的时候，经常会发现多线程程序的效率很低，但是又不知道问题出在哪里，就知道上下文切换很多，但是为什么上下文切换，是谁导致切换，我们就不知道了。上下文切换可以用dstat这样的工具查看，比如：

$dstat
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int c

查看全文: http://www.udpwork.com/item/4664.html

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

本文链接地址: systemtap函数调用栈信息不齐的原因和解决方法

有时候在看系统代码的时候，我们很难从源码中看出我们感兴趣的函数是如何被调用的，因为调用路径有可能太多。用户空间的程序gdb设断点是个好的方法，内核的就麻烦了。这时候systemtap可以帮忙, 比如:

$uname -r
2.6.18-164.el5

$stap -V
SystemTap translator/driver (version 1.5/0.137 non-git sources)
Copyright (C) 2005-2011 Red Hat, Inc. and others
This i

查看全文: http://www.udpwork.com/item/4631.html

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

本文链接地址: systemtap全局变量自动打印的原因和解决方法

在运行stap的时候,经常会发现在脚本结束运行的时候打出了很多无预期的东西,仔细一看都是些全局变量的dump, 这个问题比较烦人.

我来演示下:

$ cat > g.stp
global xyz
probe begin{
xyz=2010
exit();
}
CTRL+D

$ sudo stap g.stp
xyz=0x7da
#多余的显示,其实我们只想静悄悄的结束

查看了代码和文档发现:

A global declaration may be written at the out

查看全文: http://www.udpwork.com/item/4621.html

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

本文链接地址: 突破systemtap脚本对资源使用的限制

我们在使用脚本收集系统信息的时候经常会用到map这样的数据结构存放结果,但是stap脚本在使用过程中经常会提升说”ERROR: Array overflow, check MAXMAPENTRIES near identifier ‘a’ at test.stp:6:5″ 类似这样的信息,然后脚本就自动退出了.

这是stap运行期为了避免用户滥用系统资源做出的保护,为了安全性牺牲下方便,但是会给我们需要长期运行的脚本造成很大的麻烦,所以我们演示下如何来回避这个事情:

查看全文: http://www.udpwork.com/item/4594.html

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

本文链接地址: systemtap观察page_cache的使用情况

在规划服务器的内存使用的时候经常需要知道应用在理想情况下会使用多少的pagecache, 我们好预先把这个内存预留出来.

这个值操作系统没有提供可查看的管道,我们只能自己写个脚本来实现.

下面的systemtap脚本每隔N秒显示下当前os下头10个文件占用多少的pagecache, 降序排列.

$ cat > pagecache.stp
global __filenames
global pagecache

probe vfs.add_to_page_cache
{
pagecache[

查看全文: http://www.udpwork.com/item/4567.html

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

本文链接地址: Systemtap辅助设置tcp_init_cwnd,免对操作系统打Patch

前段时间google的工程师提出对tcp的拥塞窗口的初始值进行增大可以显著的提高http的性能，这个主要是针对tcp的slow start的优化.

具体参考这里, 这里. 谢谢叔度同学从美国带回第一手信息!

由于低版本的linux内核的问题，这个参数的正确设置需要对os打patch,这个过程对线上机器来讲非常麻烦。 底下我用systemtap给出了个解决方案，免除这个麻烦. 我们在RHEL 5U4上作这个试验:

首先需要在开发机器上:

#安装符号信息
$uname -r

查看全文: http://www.udpwork.com/item/4558.html