Linux性能优化实战
倪朋飞
微软资深工程师,Kubernetes项目维护者
立即订阅
23395 人已学习
课程目录
已完结 64 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (2讲)
开篇词 | 别再让Linux性能问题成为你的绊脚石
免费
01 | 如何学习Linux性能优化?
CPU 性能篇 (13讲)
02 | 基础篇:到底应该怎么理解“平均负载”?
03 | 基础篇:经常说的 CPU 上下文切换是什么意思?(上)
04 | 基础篇:经常说的 CPU 上下文切换是什么意思?(下)
05 | 基础篇:某个应用的CPU使用率居然达到100%,我该怎么办?
06 | 案例篇:系统的 CPU 使用率很高,但为啥却找不到高 CPU 的应用?
07 | 案例篇:系统中出现大量不可中断进程和僵尸进程怎么办?(上)
08 | 案例篇:系统中出现大量不可中断进程和僵尸进程怎么办?(下)
09 | 基础篇:怎么理解Linux软中断?
10 | 案例篇:系统的软中断CPU使用率升高,我该怎么办?
11 | 套路篇:如何迅速分析出系统CPU的瓶颈在哪里?
12 | 套路篇:CPU 性能优化的几个思路
13 | 答疑(一):无法模拟出 RES 中断的问题,怎么办?
14 | 答疑(二):如何用perf工具分析Java程序?
内存性能篇 (8讲)
15 | 基础篇:Linux内存是怎么工作的?
16 | 基础篇:怎么理解内存中的Buffer和Cache?
17 | 案例篇:如何利用系统缓存优化程序的运行效率?
18 | 案例篇:内存泄漏了,我该如何定位和处理?
19 | 案例篇:为什么系统的Swap变高了(上)
20 | 案例篇:为什么系统的Swap变高了?(下)
21 | 套路篇:如何“快准狠”找到系统内存的问题?
22 | 答疑(三):文件系统与磁盘的区别是什么?
I/O 性能篇 (10讲)
23 | 基础篇:Linux 文件系统是怎么工作的?
24 | 基础篇:Linux 磁盘I/O是怎么工作的(上)
25 | 基础篇:Linux 磁盘I/O是怎么工作的(下)
26 | 案例篇:如何找出狂打日志的“内鬼”?
27 | 案例篇:为什么我的磁盘I/O延迟很高?
28 | 案例篇:一个SQL查询要15秒,这是怎么回事?
29 | 案例篇:Redis响应严重延迟,如何解决?
30 | 套路篇:如何迅速分析出系统I/O的瓶颈在哪里?
31 | 套路篇:磁盘 I/O 性能优化的几个思路
32 | 答疑(四):阻塞、非阻塞 I/O 与同步、异步 I/O 的区别和联系
网络性能篇 (13讲)
33 | 关于 Linux 网络,你必须知道这些(上)
34 | 关于 Linux 网络,你必须知道这些(下)
35 | 基础篇:C10K 和 C1000K 回顾
36 | 套路篇:怎么评估系统的网络性能?
37 | 案例篇:DNS 解析时快时慢,我该怎么办?
38 | 案例篇:怎么使用 tcpdump 和 Wireshark 分析网络流量?
39 | 案例篇:怎么缓解 DDoS 攻击带来的性能下降问题?
40 | 案例篇:网络请求延迟变大了,我该怎么办?
41 | 案例篇:如何优化 NAT 性能?(上)
42 | 案例篇:如何优化 NAT 性能?(下)
43 | 套路篇:网络性能优化的几个思路(上)
44 | 套路篇:网络性能优化的几个思路(下)
45 | 答疑(五):网络收发过程中,缓冲区位置在哪里?
综合实战篇 (13讲)
46 | 案例篇:为什么应用容器化后,启动慢了很多?
47 | 案例篇:服务器总是时不时丢包,我该怎么办?(上)
48 | 案例篇:服务器总是时不时丢包,我该怎么办?(下)
49 | 案例篇:内核线程 CPU 利用率太高,我该怎么办?
50 | 案例篇:动态追踪怎么用?(上)
51 | 案例篇:动态追踪怎么用?(下)
52 | 案例篇:服务吞吐量下降很厉害,怎么分析?
53 | 套路篇:系统监控的综合思路
54 | 套路篇:应用监控的一般思路
55 | 套路篇:分析性能问题的一般步骤
56 | 套路篇:优化性能问题的一般方法
57 | 套路篇:Linux 性能工具速查
58 | 答疑(六):容器冷启动如何性能分析?
加餐篇 (4讲)
加餐(一) | 书单推荐:性能优化和Linux 系统原理
加餐(二) | 书单推荐:网络原理和 Linux 内核实现
用户故事 | “半路出家 ”,也要顺利拿下性能优化!
用户故事 | 运维和开发工程师们怎么说?
结束语 (1讲)
结束语 | 愿你攻克性能难关
Linux性能优化实战
登录|注册

27 | 案例篇:为什么我的磁盘I/O延迟很高?

倪朋飞 2019-01-21
你好,我是倪朋飞。
上一节,我们研究了一个狂打日志引发 I/O 性能问题的案例,先来简单回顾一下。
日志,是了解应用程序内部运行情况,最常用也是最有效的工具。日志一般会分为调试、信息、警告、错误等多个不同级别。
通常,生产环境只用开启警告级别的日志,这一般不会导致 I/O 问题。但在偶尔排查问题时,可能需要我们开启调试日志。调试结束后,很可能忘了把日志级别调回去。这时,大量的调试日志就可能会引发 I/O 性能问题。
你可以用 iostat ,确认是否有 I/O 性能瓶颈。再用 strace 和 lsof ,来定位应用程序以及它正在写入的日志文件路径。最后通过应用程序的接口调整日志级别,完美解决 I/O 问题。
不过,如果应用程序没有动态调整日志级别的功能,你还需要修改应用配置并重启应用,以便让配置生效。
今天,我们再来看一个新的案例。这次案例是一个基于 Python Flask 框架的 Web 应用,它提供了一个查询单词热度的 API,但是 API 的响应速度并不让人满意。
非常感谢携程系统研发部资深后端工程师董国星,帮助提供了今天的案例。

案例准备

本次案例还是基于 Ubuntu 18.04,同样适用于其他的 Linux 系统。我使用的案例环境如下所示:
机器配置:2 CPU,8GB 内存
预先安装 docker、sysstat 等工具,如 apt install docker.io sysstat
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Linux性能优化实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(23)

  • 划时代
    赞同在strace -p PID后加上-f,多进程和多线程都可以跟踪。

    作者回复: 👍

    2019-01-21
    36
  • jeff
    写文件是由子线程执行的,所以直接strace跟踪进程没有看到write系统调用,可以通过pstree查看进程的线程信息,再用strace跟踪。或者,通过strace -fp pid 跟踪所有线程。

    作者回复: 👍 默认选项是不开启线程的

    2019-01-21
    20
  • 我来也
    [D27打卡]
    还好我平常习惯用 `pidstat -wut 1` 既可以看上下文切换 又可以看cpu使用统计 还可以看各线程.

    今天又见识到了两个工具:
    filetop:可以查看进程操作的文件名称等信息
    opensnoop:甚至连操作的文件路径也有.

    看评论还知道了 strace 可以追逐子线程.
    ` strace -p 3387 -f 2>&1 | grep write `
    这样之后就可以搜索到很多系统调用了.

    应该跟什么语言运行 和 在哪运行没关系,最终都是要落实到系统调用上去的吧.
    2019-01-22
    6
  • 萧易客
    perf record -e 'fs:*' -ag
    perf report
    使用perf命令可以从kernel层级记录文件系统的内核事件,相对strace我觉得perf还有一个优势就是对系统的消耗更低,更利于在生产环境使用。
    http://www.brendangregg.com/perf.html

    作者回复: 嗯嗯,谢谢分享新的思路。

    不过perf report 更多的是统计上的分析,而 strace 则是可以看到每一个调用的细节。

    2019-01-23
    5
  • 郭江伟
    strace -p -f可以查看进程的所有线程信息,本例中python进程下可能同时存在两个线程,一个线程是socket相关,一个是跟文件读写相关,与文件读写相关的会频繁变化,只需跟踪进程树的最后一个线程就可以。
    可以用pstree -p 查看Python的进程树,然后strace -p 线程号,不过本例中线程消失非常快,需要写个脚本才行 比如:Python进程号是13205 strace -p `pstree -p 13205 | tail -n 1 | awk -F '(' '{print $NF}' | awk -F ')' '{print $1}'

    作者回复: 赞,很好的思路

    2019-01-23
    5
  • Geek_00d753
    老师,请教个问题。在cpu密集型任务中一个进程的cpu利用率是各cpu的us%+sy%之和。但当iow%高的时候,这个进程的cpu利用率是怎么算的呢?就像第一个例子中,进程cpu利用率14%,比两个cpu的us%+sy%大很多。我之前理解的iow状态,进程在等io资源,这个时候应该是off-cpu的,是不是我理解错了。难道iow%有一部分也算是cpu占用的吗?那又是怎么计算的呢?谢谢

    作者回复: 很好的问题。多个工具对比计算的时候一定要使用相同的时间间隔,间隔不同时,很可能就会碰到这个问题

    2019-03-21
    2
  • 不用那么麻烦吧,一般看用户进程cpu高的,iowait显著的话,直接lsof -p就能找到了什么文件了

    作者回复: 简单场景一条 lsof 就解决了,但复杂的场景则还需要更多的步骤

    2019-01-22
    1
  • 仲鬼
    老师好,案例里pidstat的iodelay为0,kB_wr/s也有300MB,是否说明应用程序写文件的性能没有收到影响,造成进程响应慢的可能是其他问题(如系统调用、打开文件等)?

    作者回复: 应该反过来,进程大量的 I/O 时,自己可能问题不大,但却导致了其他进程出现问题

    2019-01-22
    1
  • 我来也
    [D27打卡]
    Ubuntu 18.04在安装bcc时出错,然后参考[https://www.codetd.com/article/3092913]可以成功安装.

    因为ppa:hzwhuang/ss-qt5 并没有18.04版本的源,因此会出现
    E: 仓库 “http://ppa.launchpad.net/hzwhuang/ss-qt5/ubuntu bionic Release” 没有 Release 文件 的错误。
    这时,只要编辑/etc/apt/sources.list.d/hzwhuang-ubuntu-ss-qt5-bionic.list 文件,将bionic (18.04版本代号)改成xenial(16.04版本代号)
    然后再执行第二三步骤即可。

    作者回复: 谢谢分享

    2019-01-22
    1
  • Linuxer
    是不是strace要增加-f

    作者回复: strace默认不跟踪子线程的系统调用

    2019-01-21
    1
  • ninuxer
    打卡day28
    我一般用strace -cp 来看系统调用的统计信息,然后用-e 查看对应调用的详情

    作者回复: 嗯,不过注意strace默认不跟踪子线程的系统调用

    2019-01-21
    1
  • 远方
    使用strace时,没有加-f选项查看线程

    作者回复: 👍

    2019-01-21
    1
  • NoBody
    老师你好。我想问一下如何定位那种快速消亡的线程tid,来查找pid。我根据上面的步骤以后。filetop结束以后用ps -efT已经获取不到pid了。最后搜索用ps -eLo pid= -o tid= | awk '$2 == xxx{print $1}'成功输出pid。但是如果线程如果消亡更快的话,应该怎么定位?
    2019-09-23
  • Musisan
    docker: Error response from daemon: driver failed programming external connectivity on endpoint app (175d6e56d8b0ac97ae0ae46a8b809785dcca95481147f73b71d01670d0546ad4): (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 10000 -j DNAT --to-destination 172.17.0.2:80 ! -i docker0: iptables: No chain/target/match by that name.
     (exit status 1)).

    老师,创建docker镜像时候出现这个,无法运行成功

    作者回复: 试试重启docker

    2019-05-20
  • 大乌贼 (\(●-●)/)
    不知道是不是我ssd的原因,iowait只有一点几,反而上下文切换过多导致sy很高

    作者回复: 嗯,很有可能,试试把数据量再增大一些,iowait应该会跟着升高

    2019-04-02
  • 大飞
    打卡
    2019-04-01
  • 如果
    DAY27,打卡
    2019-03-12
  • 饼子
    打卡学习
    2019-02-05
  • zzl
    老师您好,你讲的这个正常磁盘瓶颈情况,而我经常遇到的不是这样。比如我是用的中高端存储阵列,跑的是oracle数据库,突然出现io慢的问题,查看磁盘使用率100%,io等待时间很高,io读写只有每秒几K到几兆,磁盘队列正常,完全达不到存储阵列应有的样子,而数据库方面只给出了io读写缓慢导致数据库访问缓慢,让检查系统磁盘io,应用层则是表示最近没有任何变化,突然就变慢了。遇到这种情况,没什么办法,看下存储硬件没问题就不知道该怎么办了。您看这种情况应该怎搞清楚具体底层的原因呢

    作者回复: 对数据库来说,I/O问题除了硬件错误之外,很有可能问题处在数据库本身的使用上。所以,可以从数据库的使用上去排查,比如表结构、SQL、慢查询等等

    2019-01-24
  • code2
    观察数据库系统的I/O问题时,是否注意力应集中在数据库进程上?
    2019-01-22
收起评论
23
返回
顶部