参考:https://linuxtools-rst.readthedocs.io/zh_CN/latest/advance/03_optimization.html

目录

1. 分析系统瓶颈

2. 分析内存瓶颈

3. 分析IO瓶颈

4. 分析进程调用

5. 优化程序代码

gprof使用步骤

6. 其它工具


1. 分析系统瓶颈

系统响应变慢,首先得定位大致的问题出在哪里,是IO瓶颈、CPU瓶颈、内存瓶颈还是程序导致的系统问题;

使用top工具能够比较全面的查看我们关注的点:

[root@localhost spamassassin]# top
top - 10:33:14 up 7 days, 21:14,  4 users,  load average: 0.00, 0.00, 0.00
Tasks: 112 total,   1 running, 111 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni, 99.7%id,  0.1%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   1034944k total,   909704k used,   125240k free,   440252k buffers
Swap:        0k total,        0k used,        0k free,   311284k cachedPID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                              3624 root      20   0 20860 8924 6396 S  0.3  0.9  37:10.02 smbd                                                  1 root      15   0  2072  628  544 S  0.0  0.1   0:01.19 init                                                  2 root      RT  -5     0    0    0 S  0.0  0.0   0:21.85 migration/0                                           3 root      34  19     0    0    0 S  0.0  0.0   0:00.02 ksoftirqd/0                                           4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.08 watchdog/0                                            5 root      RT  -5     0    0    0 S  0.0  0.0   0:20.81 migration/1                                           6 root      34  19     0    0    0 S  0.0  0.0   0:00.03 ksoftirqd/1                                           7 root      RT  -5     0    0    0 S  0.0  0.0   0:00.16 watchdog/1                                            8 root      RT  -5     0    0    0 S  0.0  0.0   0:22.15 migration/2                                           9 root      34  19     0    0    0 S  0.0  0.0   0:00.30 ksoftirqd/2                                           10 root      RT  -5     0    0    0 S  0.0  0.0   0:00.16 watchdog/2 

进入交互模式后:

  • 输入M,进程列表按内存使用大小降序排序,便于我们观察最大内存使用者使用有问题(检测内存泄漏问题);
  • 输入P,进程列表按CPU使用大小降序排序,便于我们观察最耗CPU资源的使用者是否有问题;

top第三行显示当前系统的,其中有两个值很关键:

  • %id:空闲CPU时间百分比,如果这个值过低,表明系统CPU存在瓶颈;
  • %wa:等待I/O的CPU时间百分比,如果这个值过高,表明IO存在瓶颈;

2. 分析内存瓶颈

查看内存是否存在瓶颈,使用top指令看比较麻烦,而free命令更为直观:

[/home/weber#]freetotal       used       free     shared    buffers     cached
Mem:        501820     452028      49792      37064       5056     136732
-/+ buffers/cache:     310240     191580
Swap:            0          0          0
[/home/weber#]top
top - 17:52:17 up 42 days,  7:10,  1 user,  load average: 0.02, 0.02, 0.05
Tasks:  80 total,   1 running,  79 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:    501820 total,   452548 used,    49272 free,     5144 buffers
KiB Swap:        0 total,        0 used,        0 free.   136988 cached Mem

top工具显示了free工具的第一行所有信息,但真实可用的内存,还需要自己计算才知道; 系统实际可用的内存为free工具输出第二行的free+buffer+cached;也就是第三行的free值191580;关于free命令各个值的详情解读,请参考这篇文章 free 查询可用内存 ;

如果是因为缺少内存,系统响应变慢很明显,因为这使得系统不停的做换入换出的工作;

进一步的监视内存使用情况,可使用vmstat工具,实时动态监视操作系统的内存和虚拟内存的动态变化。 参考: vmstat 监视内存使用情况 ;

3. 分析IO瓶颈

如果IO存在性能瓶颈,top工具中的%wa会偏高;

进一步分析使用iostat工具:

/root$iostat -d -x -k 1 1
Linux 2.6.32-279.el6.x86_64 (colin)   07/16/2014      _x86_64_        (4 CPU)Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.02     7.25    0.04    1.90     0.74    35.47    37.15     0.04   19.13   5.58   1.09
dm-0              0.00     0.00    0.04    3.05     0.28    12.18     8.07     0.65  209.01   1.11   0.34
dm-1              0.00     0.00    0.02    5.82     0.46    23.26     8.13     0.43   74.33   1.30   0.76
dm-2              0.00     0.00    0.00    0.01     0.00     0.02     8.00     0.00    5.41   3.28   0.00
  • 如果%iowait的值过高,表示硬盘存在I/O瓶颈。
  • 如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。
  • 如果 svctm 比较接近 await,说明 I/O 几乎没有等待时间;
  • 如果 await 远大于 svctm,说明I/O 队列太长,io响应太慢,则需要进行必要优化。
  • 如果avgqu-sz比较大,也表示有大量io在等待。

更多参数说明请参考 iostat 监视I/O子系统 ;

4. 分析进程调用

通过top等工具发现系统性能问题是由某个进程导致的之后,接下来我们就需要分析这个进程;继续 查询问题在哪;

这里我们有两个好用的工具: pstack和pstrace

pstack用来跟踪进程栈,这个命令在排查进程问题时非常有用,比如我们发现一个服务一直处于work状态(如假死状态,好似死循环),使用这个命令就能轻松定位问题所在;可以在一段时间内,多执行几次pstack,若发现代码栈总是停在同一个位置,那个位置就需要重点关注,很可能就是出问题的地方;

示例:查看bash程序进程栈:

/opt/app/tdev1$ps -fe| grep bash
tdev1   7013  7012  0 19:42 pts/1    00:00:00 -bash
tdev1  11402 11401  0 20:31 pts/2    00:00:00 -bash
tdev1  11474 11402  0 20:32 pts/2    00:00:00 grep bash
/opt/app/tdev1$pstack 7013
#0  0x00000039958c5620 in __read_nocancel () from /lib64/libc.so.6
#1  0x000000000047dafe in rl_getc ()
#2  0x000000000047def6 in rl_read_key ()
#3  0x000000000046d0f5 in readline_internal_char ()
#4  0x000000000046d4e5 in readline ()
#5  0x00000000004213cf in ?? ()
#6  0x000000000041d685 in ?? ()
#7  0x000000000041e89e in ?? ()
#8  0x00000000004218dc in yyparse ()
#9  0x000000000041b507 in parse_command ()
#10 0x000000000041b5c6 in read_command ()
#11 0x000000000041b74e in reader_loop ()
#12 0x000000000041b2aa in main ()

而strace用来跟踪进程中的系统调用;这个工具能够动态的跟踪进程执行时的系统调用和所接收的信号。是一个非常有效的检测、指导和调试工具。系统管理员可以通过该命令容易地解决程序问题。

参考: strace 跟踪进程中的系统调用 ;

5. 优化程序代码

优化自己开发的程序,建议采用以下准则:

  1. 二八法则:在任何一组东西中,最重要的只占其中一小部分,约20%,其余80%的尽管是多数,却是次要的;在优化实践中,我们将精力集中在优化那20%最耗时的代码上,整体性能将有显著的提升;这个很好理解。函数A虽然代码量大,但在一次正常执行流程中,只调用了一次。而另一个函数B代码量比A小很多,但被调用了1000次。显然,我们更应关注B的优化。
  2. 编完代码,再优化;编码的时候总是考虑最佳性能未必总是好的;在强调最佳性能的编码方式的同时,可能就损失了代码的可读性和开发效率;

gprof使用步骤

  1. 用gcc、g++、xlC编译程序时,使用-pg参数,如:g++ -pg -o test.exe test.cpp编译器会自动在目标代码中插入用于性能测试的代码片断,这些代码在程序运行时采集并记录函数的调用关系和调用次数,并记录函数自身执行时间和被调用函数的执行时间。
  2. 执行编译后的可执行程序,如:./test.exe。该步骤运行程序的时间会稍慢于正常编译的可执行程序的运行时间。程序运行结束后,会在程序所在路径下生成一个缺省文件名为gmon.out的文件,这个文件就是记录程序运行的性能、调用关系、调用次数等信息的数据文件。
  3. 使用gprof命令来分析记录程序运行信息的gmon.out文件,如:gprof test.exe gmon.out则可以在显示器上看到函数调用相关的统计、分析信息。上述信息也可以采用gprof test.exe gmon.out> gprofresult.txt重定向到文本文件以便于后续分析。

关于gprof的使用案例,请参考 [f1] ;

6. 其它工具

调试内存泄漏的工具valgrind,感兴趣的朋友可以google了解;

OProfile: Linux 平台上的一个功能强大的性能分析工具,使用参考 [f2] ;

除了上面介绍的工具,还有一些比较全面的性能分析工具,比如sar(Linux系统上默认不安装,需要手动安装下); 将sar的常驻监控工具打开后,能够收集比较全面的性能分析数据;

[f1]    C++的性能优化实践 http://www.cnblogs.com/me115/archive/2013/06/05/3117967.html
[f2]    用 OProfile 彻底了解性能 http://www.ibm.com/developerworks/cn/linux/l-oprof/
[f3]    Linux上的free命令详解 http://www.cnblogs.com/coldplayerest/archive/2010/02/20/1669949.html

Linux 程序性能分析与优化相关推荐

  1. linux java火焰图_Linux程序性能分析和火焰图

    Linux程序性能分析和火焰图 Linux程序的性能分析工具数量比较多,涉及到整个操作系统的方方面面,可能是开源的原因吧,相对于Windows来说丰富太多.其中应用分析性能方面Dtrace, Syst ...

  2. linux 性能 管理 与 优化

    一.影响Linux服务器性能的因素 操作系统级:CPU.内存.磁盘I/O带宽.网络I/O带宽 程序应用级 二.系统性能评估 影响性能因素   评判标准 好   坏   糟糕 CPU   user% + ...

  3. 程序性能分析及性能测试

    这里所说的程序是指对外提供tcp/ip交互协议的服务性程序.网络程序性能分析很重要,比如随着网络请求流量越来越大,我们需要知道已部署的服务能不能满足需求.这里采用对网络服务程序进行建模的方法分析影响程 ...

  4. linux启动时间极限优化,Linux启动时间的极限优化

    在上次完成嵌入式应用的Linux裁减后,Linux的启动时间仍需要7s左右,虽然勉强可以接受,但仍然没有达到我个人所追求的目标--2s以内.况且,在实际的商用环境中,设备可靠性的要求可是"5 ...

  5. Linux内核网络性能优化

    Linux内核网络性能优化 1. 前言 2. Linux网络协议栈 3. DPDK 4. XDP 4.1 XDP主要的特性 4.2 XDP与DPDK的对比 4.3 应用场景 5. CPU负载均衡 5. ...

  6. Go程序性能分析pprof

    from: Go程序性能分析pprof     参考: http://blog.golang.org/profiling-go-programs http://google-perftools.goo ...

  7. Linux启动时间的极限优化(Z)

    作者: Maco    该文章转载自网络大本营:http://xrss.cn/Info/13420.Html 在上次完成嵌入式应用的Linux裁减后,Linux的启动时间仍需要 7s 左右,虽然勉强可 ...

  8. linux优化pdf,linux系统安全和优化.pdf

    crookoo 于 2012-05-06 03:42:36发表: 好东西啊 dayed 于 2012-03-25 11:30:45发表: linux系统安全和优化 topcloud 于 2012-03 ...

  9. linux 的内核参数优化,Linux服务器内核参数优化

    Linux服务器内核参数优化 cat >> /etc/sysctl.conf << EOF #kernel optimization net.ipv4.tcp_fin_time ...

  10. Golang程序性能分析(三)用pprof分析gRPC服务的性能

    这是Golang程序性能分析系列文章的最后一篇,这次我们的主要内容是如何使用pprof工具对gRPC服务的程序性能进行分析.关于gRPC这个框架的文章之前已经写过不少文章了,如果你对它还不太熟悉,不知 ...

最新文章

  1. as3中TextFormat类的使用
  2. 【 FPGA 】认识关键BUFFER
  3. 一步一步解决 kernel 2.6 usb host driver
  4. 【Matlab 控制】多智能体一致性收敛仿真
  5. 模拟课----需求文本
  6. 《终身成长》读书笔记(part7)--社会互动是用来学习和享受的,而不是用来评判别人的
  7. Win11怎么从Dev渠道换Beta渠道?Win11从Dev渠道换Beta渠道的方法
  8. 学硬件设计,需要看哪些书籍?
  9. JAVA电影购票系统
  10. 解决gbk转utf8乱码
  11. 在家如何下载nature中的文献
  12. mysql 免费报表工具_10款最出色的免费数据库管理工具
  13. Win10下PDF打开方式经常变成系统默认应用
  14. Linerlayout Layout_wight
  15. RocketMQ:两种消费方式:pull拉、push推
  16. DS 500PM mobil便携式智能图表记录仪订购代码0500 5340_A1_B1_C1_D1_E1
  17. TS+vue3 页面红色波浪线(和声明类型有关)
  18. sql 盲注 (web渗透)
  19. lazada代运营-代运营服务平台
  20. 菜鸟教程Python教程100例(三)(持续更新)

热门文章

  1. 数据分析——Python内容学习【1】
  2. 数据压缩和归档(二)、zipfile
  3. element表格动态合并多列
  4. 驱动启动时遇到:打开服务失败(错误码=6):句柄无效 解决方案
  5. ZT android -- 蓝牙 bluetooth (二) 打开蓝牙
  6. aspose合并单元格
  7. 获取斗鱼直播间的弹幕信息
  8. axios报错Error: Request body larger than maxBodyLength limit
  9. 封装和private关键字
  10. 【Scheme归纳】1 使用Edwin