标签:
针对IO密集型应用做系统调优的时候,我们通常都需要知道系统cpu 内存 io 网络等系统性能 和 使用率,结合应用本身的访问量,以及 mysql的性能指标来综合分析。比如说:我们将系统压力情况分为三个阶段:从用户端开始到web server,再到mysql。
1. 客户量:我们可以从web app的访问log,查看访问量(通常会记录时间),
2. 系统指标: 对比dstat、 iostat/ mpstat pidstat 等搜集对应的系统性能指标,
3. mysql: 使用mysql status ,或者 mycheckpoint等工具搜集mysql的cache , query等数据。
但是问题来了,我们很容易搜集到了系统层、设备层的IO数据,但是缺少一个体贴的工具来告诉你应用打开了多少文件,文件读写比例,执行了多少次fsync,是随机读写还是顺序读写,另外,mysql是一个庞大而精心设计的系统,使用了一些列的方案如table cache, thread cache 等来提升IO,我们比较容易获得他的缓存量,命中率,文件数,但是却不好直观的知道它到底对物理IO设备读写了多少数据。
ioprofile就是这样一个工具,提供了直观的量化的数据来描述进程对io设备的真实读写量。
由于实现方式是使用strace注入到线程中,所以运行时需要sudo,方法如下:
sudo ./pt-ioprofile -p 8534 -c count
sudo ./pt-ioprofile -p 8534 -c sizes
2015年 04月 23日 星期四 17:55:35 CST Tracing process ID 8534 total read pwrite fsync open close filename 613878 613878 0 0 0 0 /redmine/mysql/data/mycheckpoint/sv_diff.frm 406924 406924 0 0 0 0 /redmine/mysql/data/mycheckpoint/sv_sample.frm 18432 0 18432 0 0 0 /redmine/mysql/data/ib_logfile1 3029 3029 0 0 0 0 /redmine/mysql/data/mycheckpoint/custom_query_view.frm
sudo ./pt-ioprofile -p 8534 -c times
2015年 04月 23日 星期四 17:54:09 CST Tracing process ID 8534 total pwrite fsync filename 0.100162 0.000271 0.099891 /redmine/mysql/data/ibdata1 0.003826 0.000000 0.003826 /redmine/mysql/data/ib_logfile0
sudo ./pt-ioprofile -p 8534 -c sizes -g filename
有人在生产环境中使用ioprofile时出现导致mysql挂起的现象,虽然是4年前了,但还是请谨慎使用。
以上数据输出中的 read write fread fwrite fsync 等指标分别是指什么呢? 多大的量才算正常?
read/write/fsync:
1. linux底层操作;
2. 内核调用, 涉及到进程上下文的切换,即用户态到核心态的转换,这是个比较消耗性能的操作。
fread/fwrite/fflush:
1. c语言标准规定的io流操作,建立在read/write/fsync之上
2. 在用户层, 又增加了一层缓冲机制,用于减少内核调用次数,但是增加了一次内存拷贝。
关系参看下图:
1. 对于输入设备,调用fsync/fflush将清空相应的缓冲区,其内数据将被丢弃;
2. 对于输出设备或磁盘文件,fflush只能保证数据到达内核缓冲区,并不能保证数据到达物理设备, 因此应该在调用fflush后,调用fsync(fileno(stream)),确保数据存入磁盘。
参考:
1. http://blog.yufeng.info/archives/995
2. http://blog.csdn.net/ybxuwei/article/details/22727565
PERCONA-TOOLKIT : pt-ioprofile分析IO情况
标签:
原文地址:http://www.cnblogs.com/zengkefu/p/5638418.html