- 2019-01-25打卡day30
io问题一般都是先top发展iowait比较高，然后iostat看是哪个进程比较高，然后再通过strace，lsof找出进程在读写的具体文件，然后对应的分析 27 
2019-01-25老师，有个问题咨询下，为什么top显示 iowait比较高，但是使用iostat却发现io的使用率并不高那？作者回复: iowait不代表磁盘I/O存在瓶颈，只是代表CPU上I/O操作的时间占用的百分比。假如这时候没有其他进程在运行，那么很小的I/O就会导致iowait升高
1 18
2019-02-06打卡day30
IO性能问题首先可以通过top 查看机器的整体负载情况，一般会出现CPU 的iowait 较高的现象
然后使用 pidstat -d 1 找到读写磁盘较高的进程
然后通过 strace -f -TT 进行跟踪，查看系统读写调用的频率和时间
通过lsof 找到 strace 中的文件描述符对应的文件 opensnoop可以找到对应的问题位置
推测 对应的问题，mysql 案例中的大量读，可能是因为没有建立索引导致的全表查询，从而形成了慢查询的现象。redis 中则是因为 备份文件设置的不合理导致的每次查询都会写磁盘。当然不同的问题还需要结合对应的情况进行分析展开作者回复: 👍
11
2019-01-25进程iowait高，磁盘iowait不高，说明是单个进程使用了一些blocking的磁盘打开方式，比如每次都fsync 8- 2019-01-26nsenter --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展开作者回复: 谢谢分享
3 
2019-01-25git 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- 2019-01-25curl 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/ 后面需要一个数字
2 
2019-01-25top、iostat、pidstat、strace，以及对应用程序的了解，MySQL、Redis本质上也是一款应用程序。 2
2019-03-17nsenter报了loadlocale.c assertion设置
export LC_ALL=C
即可作者回复: 谢谢分享
1
2019-02-28老师您好，一直在听您的视频，发现您用了很多的小工具来检查系统性能指标，而我们公司使用nmon工具，就能一次性将几乎所有常用的指标全部获取到了，而且还能拿到历史数据，请问我们用nmon是否就能在大部分情况下取到了您说的top pidstat等工具呢，如果不可以那您能说说原因吗？非常感谢作者回复: 嗯，实际使用中，使用类似nmon这种监控系统是更推荐的做法。不过，在监控系统的间隔时间不够小，或者指标不够全的时候，还是需要到系统上去抓取更多的细节
1
2019-02-11前段时间刚找到一个由于内存数据被交换到swap文件中导致内存数据遍历效率变低的问题 问题定位过程是使用pidstat命令发现进程cpu使用率变低 mpstat命令观察到系统iowait升高 由此怀疑跟io有什么关系 perf命令观察发现内存数据遍历过程中swap相关调用时间占比有点异常 然后使用pidstat命令+r参数 也观察到进程在那段时间主缺页中断升高 由此确定问题
老师的课程非常有用 多多向您学习 希望老师能多分享一些定位网络延迟问题的方法 不仅仅局限在ping探测作者回复: 谢谢分享性能排查的经验👍
1
2020-01-14可是我觉的一个基于redis请求200毫秒也慢了点
2020-01-10感谢 学到了一套查询问题的方式
2019-09-07非常好的案例，还顺复习了 redis 知识。我的环境把初始缓存数据加到 10000 后，iowait 也不是很高...
2019-03-14DAY29，打卡
2019-03-08非常经典的redis查询响应慢问题定位
2019-02-20请教个问题：我用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-13学习打卡- 2019-01-29Device: 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-26[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步获取的信息,找源码或看系统配置.确定问题,做出调整.然后收工.展开作者回复: 如果能一个套路查遍所有问题就好了😓我相信很多人都期待这样