我们在Linux上总是要保存数据的，数据要么保存在文件系统里(如ext3)，要么就在裸设备里面。我们在使用这些数据的时候都是通过文件这个抽象来访问的，操作系统会把我们需要的数据给我们，我们通常无需和块设备打交道。
从下图我们可以很清楚的看到：
我们会发现IO是个层次很深的子系统，有很复杂的数据流动线路。
至于操作系统如何去存储和获取这些数据对我们完全是黑盒子的，这通常不是问题。但是如果我们的IO很密集，我们就需要搞清楚IO具体是如何运作的，免的滥用IO和导致设计问题。
这时候你就需要blktrace这样的工具。
blktrace is a block layer IO tracing mechanism which provides detailed information about request queue operations up to user space.
它的作者Jens Axboe， 是内核IO模块的维护者，目前就职于FusionIO, 是个很nice的家伙，同时他还是著名IO评测工具fio的作者。
相关的文档：
users guide: http://pdfedit.petricek.net/bt/file_download.php?file_id=17&type=bug
HP的人写的指南： http://www.gelato.org/pdf/apr2006/gelato_ICE06apr_blktrace_brunelle_hp.pdf
CU上的小伙子写的： http://linux.chinaunix.net/bbs/viewthread.php?tid=1115851&extra=&ordertype=2
目前blktrace在大部分的Linux发行版都支持的，我们可以轻松的安装使用：
Read more…
最近在调查lockless的ring_buffer的时候,发现了ftrace.
ftrace是 Linux 内核中提供的一种调试工具。使用 ftrace 可以对内核中发生的事情进行跟踪，这在调试 bug 或者分析内核时非常有用.
什么是ftrace: 请参考http://lwn.net/Articles/322666/
什么是trace-cmd – command line reader for ftrace: 请参考http://lwn.net/Articles/341902/
trace-cmd配置: 请参考 http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-Realtime_Specific_Tuning-Latency_Tracing_Using_trace_cmd.html
ftrace在2.6.28-rc2以后的Linux内核都支持的, 当然包括RHEL6(2.6.32), 我粗粗的演示下ubuntu 10.10下的使用:
Read more…
我们在做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…
我们在做服务器的时候，老大扔给你一台机器，要你在上面开发。通常服务器软件是非常依赖于系统的软硬件的，软件通常是要紧贴硬件的特性，如果我们不能了解机器的硬件，我们就无法高效的开发。
比如说想知道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…
Linux下有时候我们需要知道一个进程在做什么，比如说程序不正常的时候，他到底在干吗？最直接的方法就是打印出他所有线程的调用栈，这样我们从栈再配合程序代码就知道程序在干吗了。
Linux下这个工具叫做pstack. 使用方法是
# pstack
Usage: pstack <process-id>
当然这个被调查的程序需要有符号信息。 比较雷人的是 这个程序竟然是个shell脚本，核心实现是gdb的 thread apply all bt， 我们可以观摩下他的实现，这个我们做类似的程序提供了一个很好的思路：
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…
Recent Comments