29 | 案例篇：Redis响应严重延迟，如何解决？

倪朋飞

你好，我是倪朋飞。
上一节，我们一起分析了一个基于 MySQL 的商品搜索案例，先来回顾一下。
在访问商品搜索接口时，我们发现接口的响应特别慢。通过对系统 CPU、内存和磁盘 I/O 等资源使用情况的分析，我们发现这时出现了磁盘的 I/O 瓶颈，并且正是案例应用导致的。
接着，我们借助 pidstat，发现罪魁祸首是 mysqld 进程。我们又通过 strace、lsof，找出了 mysqld 正在读的文件。根据文件的名字和路径，我们找出了 mysqld 正在操作的数据库和数据表。综合这些信息，我们猜测这是一个没利用索引导致的慢查询问题。
为了验证猜测，我们到 MySQL 命令行终端，使用数据库分析工具发现，案例应用访问的字段果然没有索引。既然猜测是正确的，那增加索引后，问题就自然解决了。
从这个案例你会发现，MySQL 的 MyISAM 引擎，主要依赖系统缓存加速磁盘 I/O 的访问。可如果系统中还有其他应用同时运行， MyISAM 引擎很难充分利用系统缓存。缓存可能会被其他应用程序占用，甚至被清理掉。
所以，一般我并不建议，把应用程序的性能优化完全建立在系统缓存上。最好能在应用程序的内部分配内存，构建完全自主控制的缓存；或者使用第三方的缓存应用，比如 Memcached、Redis 等。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Linux 性能优化实战》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(32)

最新
精选

李博
老师，有个问题咨询下，为什么top显示 iowait比较高，但是使用iostat却发现io的使用率并不高那？
作者回复: iowait不代表磁盘I/O存在瓶颈，只是代表CPU上I/O操作的时间占用的百分比。假如这时候没有其他进程在运行，那么很小的I/O就会导致iowait升高
4
50
Geek_33409b
打卡day30 IO性能问题首先可以通过top 查看机器的整体负载情况，一般会出现CPU 的iowait 较高的现象然后使用 pidstat -d 1 找到读写磁盘较高的进程然后通过 strace -f -TT 进行跟踪，查看系统读写调用的频率和时间通过lsof 找到 strace 中的文件描述符对应的文件 opensnoop可以找到对应的问题位置推测对应的问题，mysql 案例中的大量读，可能是因为没有建立索引导致的全表查询，从而形成了慢查询的现象。redis 中则是因为备份文件设置的不合理导致的每次查询都会写磁盘。当然不同的问题还需要结合对应的情况进行分析
作者回复: 👍
4
27
____的我
前段时间刚找到一个由于内存数据被交换到swap文件中导致内存数据遍历效率变低的问题问题定位过程是使用pidstat命令发现进程cpu使用率变低 mpstat命令观察到系统iowait升高由此怀疑跟io有什么关系 perf命令观察发现内存数据遍历过程中swap相关调用时间占比有点异常然后使用pidstat命令+r参数也观察到进程在那段时间主缺页中断升高由此确定问题老师的课程非常有用多多向您学习希望老师能多分享一些定位网络延迟问题的方法不仅仅局限在ping探测
作者回复: 谢谢分享性能排查的经验👍

12
yungoo
nsenter报了loadlocale.c assertion设置 export LC_ALL=C 即可
作者回复: 谢谢分享

11
武文文武
老师您好，一直在听您的视频，发现您用了很多的小工具来检查系统性能指标，而我们公司使用nmon工具，就能一次性将几乎所有常用的指标全部获取到了，而且还能拿到历史数据，请问我们用nmon是否就能在大部分情况下取到了您说的top pidstat等工具呢，如果不可以那您能说说原因吗？非常感谢
作者回复: 嗯，实际使用中，使用类似nmon这种监控系统是更推荐的做法。不过，在监控系统的间隔时间不够小，或者指标不够全的时候，还是需要到系统上去抓取更多的细节
2
10
利俊杰
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
作者回复: 谢谢分享

5
从远方过来
老师，你这几篇文章大量使用了strace，它的负载不是很高么？在生产上可以使用么？
作者回复: 是的，strace会影响性能，所以一般不使用它来做监控。但是在已经出现严重性能问题的时候，使用它来排查问题还是可以接受的。

4
开始懂了
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/ 后面需要一个数字

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

2
我来也
[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步获取的信息,找源码或看系统配置.确定问题,做出调整.然后收工.
作者回复: 如果能一个套路查遍所有问题就好了😓我相信很多人都期待这样

1

收起评论