今天中午吃完饭遇到的问题 问题描述: dev 环境,开发忽然反映他的 docker 应用 restart 不了,也停止不了,使用 htop 直接黑屏
初步诊断: top 查看,load 28 左右,但是所有核心的 CPU 使用率那一行,idle 几乎接近 100%(是所有核心), swap 仅剩几十 M
开始怀疑是 load 高,就先把其他吃 cpu 的程序关了试试把 load 降下来先,然后发现并没有降下来。
反而定位过程执行的诸如 ps,htop top 进一步分析,load 高的主要原因是 R ( Running )和 D ( Uninterruptible sleep )状态进程等待导致。 ps -eTo stat,pid,tid,ppid,comm --no-header | sed -e 's/^ *//' | perl -nE 'chomp;say if (m!^\S*[RD]+\S*!)' 发现 D 状态的就有那个无法操作的 docker 程序的 node 进程,以及前面卡死的 ps,htop 等进程。 D 状态进程是由于在等待 Io (磁盘或者网络) 查看 io,没发现磁盘有大量读写出入,网络也没有 机房检查硬盘,没问题,也试过写入文件和删除,都正常
这里我已觉得是磁盘有问题,但是不清楚下一步高如何去定位。
后面开发急着使用,就只能给他们重启服务器了( D 状态进程,无法 Kill ) 重启后,一切恢复正常。
请问有经验的 V2er,这种情况该如何定位下一步?我还是想了解完整的问题,或者解决问题的思路
非常感谢。
1
kevin1234 2018-12-19 20:29:47 +08:00
先停掉一切可以停掉的应用再看 不然现在你操作不了 也看不到。
|
3
BraveRBT 2018-12-20 00:21:45 +08:00
啊哈,是一个常见问题了
这个问题来自对 load 的错误看法,我觉得确实是这样的... 其实 load 反应的并不只是” CPU 忙碌程度“,而是目前状态 R 的程序数量或者等待 I/O 的程序 关于这个的具体说明请 man proc, 查看段落关键字 /proc/loadavg 其实你的猜想是部分正确的,这个问题极有可能是因为非常高的%wa 时间导致 同时也有可能是 docker daemon 尝试重启而 hang 住导致的,下次分析的时候可以看看多个维度的指标和数据 |
4
chickplilita 2018-12-20 00:24:55 +08:00
load 高,cpu 低,就是在等 io 网络或者磁盘的。磁盘要么是 hang 住了,可以看 dmesg 里面的错误。网络的等待就要具体看了。
|
5
chickplilita 2018-12-20 00:25:29 +08:00
perf analysis
https://medium.com/netflix-techblog/linux-performance-analysis-in-60-000-milliseconds-accc10403c55 这个是所谓的 60 秒分析大法。 uptime dmesg | tail vmstat 1 mpstat -P ALL 1 pidstat 1 iostat -xz 1 free -m sar -n DEV 1 sar -n TCP,ETCP 1 top |
6
BraveRBT 2018-12-20 00:33:15 +08:00
补充上面的一句话,少说了一个词:”其实 load 反应的并不只是” CPU 忙碌程度“,而是目前状态 R 的程序数量或者等待 I/O 的程序数量之和(也就是你说的状态 D 的进程)“
另外似乎某些时候文件系统 inode 被耗尽或者磁盘满了也有可能导致这样的问题。 下次再遇到这样的问题可以试试获取更多信息研究一下,说不定就能找到问题的根本所在了。 htop/top/ps/iotop/iostat 在这些时候都能发挥作用,综合他们的数据来分析问题吧。 |
7
imfannet 2018-12-20 08:16:12 +08:00
据本菜鸡日常折腾的情况 高负载低 CPU 一般都是硬盘的锅 比如队列 100% 读写延迟爆表之类的。。。
|
8
Bardon 2018-12-20 08:30:01 +08:00
哦,经常遇到
docker 是个好东西,但是 docker 的文件系统性能真的不敢恭维,哪怕是 overlay2 |
9
sagaxu 2018-12-20 09:20:30 +08:00 via Android 1
swap 仅剩几十 M 能不卡吗?
|