Linux性能优化实战
倪朋飞
微软资深工程师,Kubernetes项目维护者
立即订阅
23325 人已学习
课程目录
已完结 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性能优化实战
登录|注册

29 | 案例篇:Redis响应严重延迟,如何解决?

倪朋飞 2019-01-25
你好,我是倪朋飞。
上一节,我们一起分析了一个基于 MySQL 的商品搜索案例,先来回顾一下。
在访问商品搜索接口时,我们发现接口的响应特别慢。通过对系统 CPU、内存和磁盘 I/O 等资源使用情况的分析,我们发现这时出现了磁盘的 I/O 瓶颈,并且正是案例应用导致的。
接着,我们借助 pidstat,发现罪魁祸首是 mysqld 进程。我们又通过 strace、lsof,找出了 mysqld 正在读的文件。根据文件的名字和路径,我们找出了 mysqld 正在操作的数据库和数据表。综合这些信息,我们猜测这是一个没利用索引导致的慢查询问题。
为了验证猜测,我们到 MySQL 命令行终端,使用数据库分析工具发现,案例应用访问的字段果然没有索引。既然猜测是正确的,那增加索引后,问题就自然解决了。
从这个案例你会发现,MySQL 的 MyISAM 引擎,主要依赖系统缓存加速磁盘 I/O 的访问。可如果系统中还有其他应用同时运行, MyISAM 引擎很难充分利用系统缓存。缓存可能会被其他应用程序占用,甚至被清理掉。
所以,一般我并不建议,把应用程序的性能优化完全建立在系统缓存上。最好能在应用程序的内部分配内存,构建完全自主控制的缓存;或者使用第三方的缓存应用,比如 Memcached、Redis 等。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Linux性能优化实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(19)

  • ninuxer
    打卡day30
    io问题一般都是先top发展iowait比较高,然后iostat看是哪个进程比较高,然后再通过strace,lsof找出进程在读写的具体文件,然后对应的分析
    2019-01-25
    26
  • 李博
    老师,有个问题咨询下,为什么top显示 iowait比较高,但是使用iostat却发现io的使用率并不高那?

    作者回复: iowait不代表磁盘I/O存在瓶颈,只是代表CPU上I/O操作的时间占用的百分比。假如这时候没有其他进程在运行,那么很小的I/O就会导致iowait升高

    2019-01-25
    1
    16
  • 陈云卿
    打卡day30
    IO性能问题首先可以通过top 查看机器的整体负载情况,一般会出现CPU 的iowait 较高的现象
    然后使用 pidstat -d 1 找到读写磁盘较高的进程
    然后通过 strace -f -TT 进行跟踪,查看系统读写调用的频率和时间
    通过lsof 找到 strace 中的文件描述符对应的文件 opensnoop可以找到对应的问题位置
    推测 对应的问题,mysql 案例中的大量读,可能是因为没有建立索引导致的全表查询,从而形成了慢查询的现象。redis 中则是因为 备份文件设置的不合理导致的每次查询都会写磁盘。当然不同的问题还需要结合对应的情况进行分析

    作者回复: 👍

    2019-02-06
    9
  • Christmas
    进程iowait高,磁盘iowait不高,说明是单个进程使用了一些blocking的磁盘打开方式,比如每次都fsync
    2019-01-25
    8
  • 利俊杰
    nsenter --target $PID -- lsof -i
    执行失败,提示:loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed
    可以参考下https://stackoverflow.com/questions/37121895/yocto-build-loadlocale-c-130
    配置
    LANG=/usr/lib/locale/en_US

    作者回复: 谢谢分享

    2019-01-26
    3
  • 往事随风,顺其自然
    git clone https://github.com/feiskyer/linux-perf-examples/tree/master/redis-slow
    Initialized empty Git repository in /root/redis-slow/.git/
    error: The requested URL returned error: 403 Forbidden while accessing https://github.com/feiskyer/linux-perf-examples/tree/master/redis-slow/info/refs

    代码怎么克隆不下来

    作者回复: clone要指定代码仓库的路径,而不是子目录:

    git clone https://github.com/feiskyer/linux-perf-examples

    2019-01-25
    2
  • 开始懂了
    curl http://10.39.25.7:10000/init/get_cache
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
    <title>500 Internal Server Error</title>
    <h1>Internal Server Error</h1>
    <p>The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.</p>

    作者回复: /init/ 后面需要一个数字

    2019-01-25
    2
  • Cranliu
    top、iostat、pidstat、strace,以及对应用程序的了解,MySQL、Redis本质上也是一款应用程序。
    2019-01-25
    2
  • yungoo
    nsenter报了loadlocale.c assertion设置

    export LC_ALL=C

    即可

    作者回复: 谢谢分享

    2019-03-17
    1
  • 武文文武
    老师您好,一直在听您的视频,发现您用了很多的小工具来检查系统性能指标,而我们公司使用nmon工具,就能一次性将几乎所有常用的指标全部获取到了,而且还能拿到历史数据,请问我们用nmon是否就能在大部分情况下取到了您说的top pidstat等工具呢,如果不可以那您能说说原因吗?非常感谢

    作者回复: 嗯,实际使用中,使用类似nmon这种监控系统是更推荐的做法。不过,在监控系统的间隔时间不够小,或者指标不够全的时候,还是需要到系统上去抓取更多的细节

    2019-02-28
    1
  • ____的我
    前段时间刚找到一个由于内存数据被交换到swap文件中导致内存数据遍历效率变低的问题 问题定位过程是使用pidstat命令发现进程cpu使用率变低 mpstat命令观察到系统iowait升高 由此怀疑跟io有什么关系 perf命令观察发现内存数据遍历过程中swap相关调用时间占比有点异常 然后使用pidstat命令+r参数 也观察到进程在那段时间主缺页中断升高 由此确定问题

    老师的课程非常有用 多多向您学习 希望老师能多分享一些定位网络延迟问题的方法 不仅仅局限在ping探测

    作者回复: 谢谢分享性能排查的经验👍

    2019-02-11
    1
  • 饭粒
    非常好的案例,还顺复习了 redis 知识。我的环境把初始缓存数据加到 10000 后,iowait 也不是很高...
    2019-09-07
  • 如果
    DAY29,打卡
    2019-03-14
  • 云学
    非常经典的redis查询响应慢问题定位
    2019-03-08
  • Chn.K
    请教个问题:我用iotop观测IO使用情况,发现某进程的DISK READ 和DISK WRITE都是0,但是IO已经到99.99%了,通过top/iostat对cpu/磁盘的使用情况进行观测,均未发现什么异常,这个是什么原因呢?
    Total DISK READ : 18.14 M/s | Total DISK WRITE : 31.59 M/s
    Actual DISK READ: 18.02 M/s | Actual DISK WRITE: 15.60 M/s
      PID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
      148 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [ksoftirqd/17]
    23655 be/4 root 0.00 B/s 988.19 K/s 0.00 % 0.00 % ./xxxx ../etc/base.conf
    17535 be/4 root 18.14 M/s 30.63 M/s 0.00 % 0.00 % xxxx

    作者回复: 这个IO 99%跟你想的磁盘IO使用99%是不一样的,具体含义你可以去查一下iotop的文档

    2019-02-20
  • 饼子
    学习打卡
    2019-02-13
  • 李逍遥
    Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
    vda 0.00 392.00 0.00 1103.00 0.00 5984.00 10.85 1.00 0.58 0.00 0.58 0.91 100.00
    我这边 %util到了100%,说明磁盘有瓶颈了吗?(请求参数一致)

    作者回复: 一般来说是的。不过如果磁盘支持并发写的话,实际上这时候磁盘还是可以继续接受其他的写请求,所以这不是绝对的。最好是做个基准测试,这样以后再观察的时候就有了对比的基准。

    2019-01-29
  • 我来也
    [D29打卡]
    感觉每次分析的套路都差不多.
    1.用top查看指标,发现 [系统] 有i/o瓶颈 或者 cpu瓶颈.
    2.使用iostat辅助看下磁盘i/o读写速度和大小等指标.
    3.用pidstat判断是哪个 [进程] 导致的. 既可以看进程各线程的cpu中断数,也可以看磁盘io数.
    4.用strace追踪进程及各线程的 [系统调用].(以前经常到这里就知道了是操作的什么文件)
    5.继续用lsof查看该进程打开的 [文件] .linux下一切皆文件,则可以查看的东西就很多很多了.连进程保持的socket等信息也一目了然.
    6.本例因为用到了容器,所以用到了nsenter进入容器的网络命名空间,查看对应的socket信息.
    7.根据第4.5步获取的信息,找源码或看系统配置.确定问题,做出调整.然后收工.

    作者回复: 如果能一个套路查遍所有问题就好了😓我相信很多人都期待这样

    2019-01-26
  • 夹心面包
    想请问下老师,通过top观察下的iowait到达百分之多少才算磁盘瓶颈,有没有业界的统一标准,磁盘的util值肯定是100%,还是得考虑IOPS,只通过iowait判断行不行

    作者回复: 只用iowait不能说明磁盘瓶颈,需要用 iostat

    2019-01-25
收起评论
19
返回
顶部