嵌入式Linux内存使用与性能优化.doc

嵌入式Linux内存使用与性能优化 5.4 性能分析 5.4 性能分析 3种原因。 （1）程序的运算量很大，导致CPU过于繁忙，CPU是瓶颈。 可以在设备上运行“top”命令，如果某个进程的CPU利用率很高，则说明CPU是性能瓶颈。 （2）程序需要做大量的I/O，读写文件、内存操作等等，CPU更多的是处于等待，I/O部分成为程序性能的瓶颈。 运行“top”命令，系统内进程的CPU利用率并不高，这时可以通过proc目录下的相关文件（后面将会讲到）查看系统I/O情况。如果系统存在大量的I/O，则可以断定I/O为性能瓶颈。 对于大量I/O操作引起的程序性能问题，笔者向大家推荐一篇文章：《使用异步I/O大大提高应用程序的性能》，网址是/developerworks /cn/linux/l-async/。这篇文章说得很透彻，也很详细，笔者就不再重复了。 （3）程序之间相互等待，结果CPU利用率很低，但运行速度依然很慢，程序间的共享与死锁制约了程序的性能。 如果系统的CPU利用率并不高，而且也不存在大量的I/O操作，那么很可能是多个线程之间相互等待造成的，这时就需要对程序进行大规模的重构。 本书将性能优化的重点放在第一种情况。 proc目录 通过proc目录，能够了解到CPU和IO设备的工作状况，从而能够帮助分析导致程序性能低下的原因。 1．系统相关 还是先通过proc目录，了解整个系统的性能。 # cat /proc/stat cpu 5116 0 7801 249195 60 41 55 cpu0 5116 0 7801 249195 60 41 55 intr 364129 0 0 0 0 0 0 0 0 7 7 93 0 0 0 0 69 0 0 0 0 3 4250 0 0 1 0 0 0 8561 262014 0 0 0 85936 839 2 0 0 1157 0 1152 0 33 0 0 0 0 1 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ctxt 231056 btime 1167696676 processes 515 procs_running 1 procs_blocked 0 因为嵌入式设备中一般只有一个CPU，所以这里只关注第一行。 cpu 5116 0 7801 249195 60 41 55 cpu后面数值分别代表着CPU在不同状态下所用的时间，其单位为jiffy（0.01s），7个数值的含义分别是： user（5116）：从系统启动开始累计到当前时刻，用户态的CPU时间，不包含nice值为负的进程。 nice（0）：从系统启动开始累计到当前时刻，nice值为负的进程所占用的CPU时间。 system（7801）：从系统启动开始累计到当前时刻，内核所占用的CPU时间。 idle（249195）：从系统启动开始累计到当前时刻，除硬盘IO等待时间以外其他等待时间。 iowait（60）：从系统启动开始累计到当前时刻，硬盘IO等待时间。 irq（41）：从系统启动开始累计到当前时刻，硬中断时间。 softirq（55）：从系统启动开始累计到当前时刻，软中断时间。 由此可以推导出：CPU时间=user+system+nice+idle+iowait+irq+softirq CPU的利用率=1-（idle）/（user+system+nice+idle+iowait+irq+softirq）。 根据CPU的利用率，可以知道当前系统的CPU的负载情况。 从这些数据中，可以分析出性能瓶颈在哪： （1）程序代码有问题，导致占用了大量的CPU，可以通过 CPU用户态利用率=（user+nice）/（user+system+nice+idle+iowait+irq+softirq）来了解。 （2）程序代码调用了大量的系统调用，导致Linux内核占用了大量的CPU，可以通过 CPU内核态利用率=（system）/（user+system+nice+idle+iowait+irq+softirq）来了解。 （3）系统和Flash、内存等有大量的交互和等待，从而导致系统