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
《Linux 性能优化实战》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(32)
- 最新
- 精选
- 李博老师,有个问题咨询下,为什么top显示 iowait比较高,但是使用iostat却发现io的使用率并不高那?
作者回复: iowait不代表磁盘I/O存在瓶颈,只是代表CPU上I/O操作的时间占用的百分比。假如这时候没有其他进程在运行,那么很小的I/O就会导致iowait升高
450 - Geek_33409b打卡day30 IO性能问题首先可以通过top 查看机器的整体负载情况,一般会出现CPU 的iowait 较高的现象 然后使用 pidstat -d 1 找到读写磁盘较高的进程 然后通过 strace -f -TT 进行跟踪,查看系统读写调用的频率和时间 通过lsof 找到 strace 中的文件描述符对应的文件 opensnoop可以找到对应的问题位置 推测 对应的问题,mysql 案例中的大量读,可能是因为没有建立索引导致的全表查询,从而形成了慢查询的现象。redis 中则是因为 备份文件设置的不合理导致的每次查询都会写磁盘。当然不同的问题还需要结合对应的情况进行分析
作者回复: 👍
427 - ____的我前段时间刚找到一个由于内存数据被交换到swap文件中导致内存数据遍历效率变低的问题 问题定位过程是使用pidstat命令发现进程cpu使用率变低 mpstat命令观察到系统iowait升高 由此怀疑跟io有什么关系 perf命令观察发现内存数据遍历过程中swap相关调用时间占比有点异常 然后使用pidstat命令+r参数 也观察到进程在那段时间主缺页中断升高 由此确定问题 老师的课程非常有用 多多向您学习 希望老师能多分享一些定位网络延迟问题的方法 不仅仅局限在ping探测
作者回复: 谢谢分享性能排查的经验👍
12 - yungoonsenter报了loadlocale.c assertion设置 export LC_ALL=C 即可
作者回复: 谢谢分享
11 - 武文文武老师您好,一直在听您的视频,发现您用了很多的小工具来检查系统性能指标,而我们公司使用nmon工具,就能一次性将几乎所有常用的指标全部获取到了,而且还能拿到历史数据,请问我们用nmon是否就能在大部分情况下取到了您说的top pidstat等工具呢,如果不可以那您能说说原因吗?非常感谢
作者回复: 嗯,实际使用中,使用类似nmon这种监控系统是更推荐的做法。不过,在监控系统的间隔时间不够小,或者指标不够全的时候,还是需要到系统上去抓取更多的细节
210 - 利俊杰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
收起评论