我们在做IO密集型的应用程序的时候，比如MySQL数据库，通常系统的表现取决于workload的类型。 比如我们要调优，我们就必须非常清楚的知道数据的访问规律，收集到足够的数据，用来做调优的依据。
有很多工具可以收集系统层面的，设备层面的，进程层面的IO数据，但是没有一个现成的工具可以回答我们比如应用打开了多少文件，文件的读和写的比例是多少，调用了多少次sync, 每次的数据大小是多少，调用了多少次，每次用了多少时间， 是顺序操作还是随机操作，是那个线程发起的操作。
当然如果你对系统足够熟悉的话，你可以用systemtap来编写脚本获取这些数据，也不是什么难事。但是大部分的同学没有足够的耐心去做这个。
这时候Percona同样来救助了。他提供了一整套工具来协助定位MySQL服务器的问题。这套工具适合于大部分的IO服务器。
Aspersa is a collection of open-source system utilities primarily designed to ease the work of Percona consultants. This manual is the primary documentation for Aspersa tools. Please contribute your improvements.
项目地址： http://code.google.com/p/aspersa/
ioprofile的使用文档： http://aspersa.googlecode.com/svn/html/ioprofile.html
它依赖于strace和lsof来做统计，所以在运行的时候会对目标系统产生一定的性能影响，不过还好，你可以指定收集数据的时间。
现在我们来试验下效果：
Read more…
看到周围的人都上了新浪围脖，我也忍不住也注册了，http://t.sina.com.cn/tchuba, 欢迎大家围观！ 我会墨迹点技术的东西。
谢谢！
我们在做服务器的时候，老大扔给你一台机器，要你在上面开发。通常服务器软件是非常依赖于系统的软硬件的，软件通常是要紧贴硬件的特性，如果我们不能了解机器的硬件，我们就无法高效的开发。
比如说想知道Linux的系统的版本，CPU有几个，内存多少大， 机器什么型号，Raid卡什么型号，硬盘有几个，文件系统是什么样子的，网卡什么型号，文件句柄设置什么的，用到虚拟化技术了吗，网络配置什么样的，目前资源使用是如何?
当然如果你足够有经验的话，这些问题难不倒你，但是你获取完全的这些信息是很麻烦的。
这时候Percona 来救助了。他提供了一整套工具来协助定位MySQL服务器的问题。这套工具适合于大部分的IO服务器。
Aspersa is a collection of open-source system utilities primarily designed to ease the work of Percona consultants. This manual is the primary documentation for Aspersa tools. Please contribute your improvements.
项目地址： http://code.google.com/p/aspersa/
summary的使用文档： http://aspersa.googlecode.com/svn/html/summary.html
我们来参观下效果：
Read more…
我们在做服务器程序的时候，经常要知道一个请求的响应时间，借以优化或者定位问题。 通常的做法是在代码里面加入日志计算时间，这个方法有问题，时间不准确。因为数据从网卡到应用程序，从应用到网卡的时间没有被计算在内。 而且这个时间随着系统的负载有很大的变化。
那同学说，我wireshark, tcpdump抓包人肉统计不行吗。 可以的，只不过我会很同情你，此举需要耐心且不具可持续性。 所以我们希望有个工具能够最少费力的做这个事情。
这时候来自percona的tcprstat来救助了！ 这个工具原本开发用来调查mysqld的性能问题，所以不要奇怪它的默认端口是3306, 但是我们可以用这个工具来调查典型的request->response类型的服务器。
什么是tcprstat:
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…
Recent Comments