1,top信息查看IOW%
adb shell top -d 1 -m 10 - t
查看IOW的百分比是不是很高,说明值得怀疑,真正是不是IO的瓶颈还详细分析应用启动时间内的IO繁忙程度。 有是有IOW%达到80%系统y额不一定很卡,有是有10%系统也会觉得卡。因为IOW是前提条件是CPU空闲,且在等待这么多IO请求,所以相同条件下的IO, CPU空闲越多,百分比越小。
2,比top更详细的系统性能操作监控,其中有IO模块监控,能实时看到IO操作量
adb shell vmstat 2
http://www.cnblogs.com/ggjucheng/archive/2012/01/05/2312625.html
bi 块设备每秒接收的块数量,这里的块设备是指系统上所有的磁盘和其他块设备,默认块大小是1024byte,我本机上没什么IO操作,所以一直是0,但是我曾在处理拷贝大量数据(2-3T)的机器上看过可以达到140000/s,磁盘写入速度差不多140M每秒
bo 块设备每秒发送的块数量,例如我们读取文件,bo就要大于0。bi和bo一般都要接近0,不然就是IO过于频繁,需要调整。
in 每秒CPU的中断次数,包括时间中断
cs 每秒上下文切换次数,例如我们调用系统函数,就要进行上下文切换,线程的切换,也要进程上下文切换,这个值要越小越好,太大了,要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中,我们一般做性能测试时会进行几千并发甚至几万并发的测试,选择web服务器的进程可以由进程或者线程的峰值一直下调,压测,直到cs到一个比较小的值,这个进程和线程数就是比较合适的值了。系统调用也是,每次调用系统函数,我们的代码就会进入内核空间,导致上下文切换,这个是很耗资源,也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换,导致CPU干正经事的时间少了,CPU没有充分利用,是不可取的。
bi 块设备每秒接收的块数量
bo 块设备每秒发送的块数量
|
bi: Blocks received from a block device (blocks/s).——每秒从块设备接收到的块数,即读块设备。
bo: Blocks sent to a block device (blocks/s).——每秒发送到块设备的块数,即写块设备。
3,还有一种命令方式查看那些线程在操作IO,以及方式:
adb shell; echo 1 > /proc/sys/vm/block_dump
adb shell dmesg > dmesg.txt
http://www.oenhan.com/block-dump-linux-io
http://itindex.net/detail/46239-linux-io-%E5%88%86%E6%9E%90
4, 一种更好的只针对IO的工具iotop,这个工具在android中没有集成,需要使用github上的开源脚本push到/system/bin中运行。
它能直接看到IO的负载是不是达到瓶颈,繁忙程度。
liunx的工具查看IO的工具, iotop.sh :
http://forum.xda-developers.com/android/software-hacking/script-iotop-android-t2910428
https://github.com/laufersteppenwolf/iotop
http://www.cnblogs.com/ggjucheng/archive/2013/01/13/2858941.html