这是一个创建于 2164 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天中午吃完饭遇到的问题 问题描述： 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 能不卡吗？
|
Select Language