☰

虚拟服务器停止响应并使用100% CPU，如何诊断？

tag-icon • tag-icon centos hang
虚拟服务器停止响应并使用100% CPU，如何诊断？

我们在 CentOS 7.4 虚拟服务器 (VMware ESXi) 上遇到了奇怪的问题，服务器在几秒钟内突然达到 100% 使用率，导致 ssh 无法工作并且正在运行的特定程序没有响应。唯一的解决方案是通过 vSphere 强制重新启动服务器。我们无法找出如此高使用率的来源，所以我的问题是，如何诊断如此突然的高使用率？有没有办法记录一些进程信息以在重新启动后进行调查？

编辑：ssh完全不起作用，事实上我做到了ssh -vvv，详细输出卡在“连接到主机端口 22”，并且 shell 永远不会返回。它似乎正在等待建立连接。关于ping，我们的 IT 工程师阻止了到服务器的 ICMP 流量，因此我无法验证ping操作。

答案1

当我遇到类似的问题时，我创建了一个像这样的小脚本（它每秒写入其 CPU 和 RAM 使用情况运行的进程的日期和列表）：

#!/bin/sh
while true
  do 
    date
    ps faux
    sleep 1
  done >> /a/log/file

我让它作为后台程序运行。这将帮助您了解流程在什么情况下以及何时变得疯狂。

之后，您将必须查看/var/log/messages其他日志（可能是来自疯狂程序的日志）以准确识别您的问题。
您还可以安装atsar它提供了惊人的二进制日志，其中包含 IO、网络活动、CPU 等统计信息日志...

/!\ Warning:
如果您运行此脚本足够长的时间，日志可能会变得很大。将日志文件放置在有足够磁盘空间的位置，否则这可能会成为一个主要问题。

/!\ Warning 2:
我不知道你的esxi设置是什么。但是，如果由于任何原因磁盘变得 esxi 广泛滞后；如果虚拟机依赖 IO，这可能会导致严重延迟和 CPU 使用率过高。

编辑2：

正如 @sourcejedi 提到的，您可以将同步添加到脚本中，以确保在硬重启时写入日志（我不确定是否有必要，但两个安全巢比一个好：

#!/bin/sh
    LOGFILE="a/log/file"
    echo "" > $LOGFILE
    while true
      do 
        date
        ps faux
        sync $LOGFILE
        sleep 1
      done >> $LOGFILE

答案2

在具有 N 个 CPU 的系统上，您可以运行 N 个用户空间线程，每个线程使用 100% 的 CPU。然而，当您尝试使用 时ssh，内核会提供ssh“公平”的 CPU 时间份额并允许您登录。

当您看到 VMware 中的 CPU 使用率为 100% 并且ssh没有响应时，内核内部可能存在忙循环。

确保您的服务器未在其本地控制台上运行图形界面。您希望处于文本模式，这样您就可以看到内核打印的任何消息。现在阅读：

文档说难的锁定检测器（又名 NMI 看门狗）默认启用。除非当内核在虚拟机中运行时它被禁用。所以在这种情况下，默认是只检测柔软的锁定。

    /*
     * Hard lockup detection is enabled by default. Disable it, as guests
     * can get false positives too easily, for example if the host is
     * overcommitted.
     */
    hardlockup_detector_disable();

--arch/x86/kernel/kvm.c: kvm_guest_init()

我对此的基本原理和历史感到困惑。我不知道为什么它认为软锁定检测器比硬锁定检测器“更安全”。最初的改变也是合理的不同的原因。 “来宾 PMU 仍在清除错误。我们的想法是，一旦 KVM PMU 足够稳定，默认情况下就会切换到默认启用的硬锁定”。最后，提到在某些版本的虚拟机管理程序上，可能根本无法启用 NMI 看门狗。

假设您没有在虚拟机管理程序中大量过度使用 CPU，您可以看看是否也可以启用 NMI 看门狗。您可以使用sysctl上面的链接，或者 sysctl 的文档说您也可以使用 kernel boot option nmi_watchdog=1。

然后测试是否可以看到内核打印的消息：

“本地控制台”是否已记录或至少是持久的，以便您会注意到上面是否打印了内核崩溃？确实应该如此，但我不确定如果您使用模拟的 vSphere 等将如何工作连续剧安慰。如果您只是使用模拟视频显示，那么它已经是持久的了。

这篇 VMWare 文章似乎依赖于相同的假设。

确保您没有禁用控制台日志记录。 运行这个命令：

sudo sh -c "echo '<3>test' >/dev/kmsg"

它应该在控制台上显示“测试”。

如果这是模拟视频显示，则部分崩溃消息可能会滚出屏幕顶部。如果内核崩溃了，那么你就不能使用shift+PageUp向上滚动。原则上，拥有一个实现回滚的模拟串行控制台会更有用。

对于内核崩溃，上面的 VMWare 链接中还有一些其他崩溃转储建议。

--Debian Stretch VM 每隔几天就会变得准无响应

链接答案中的大多数其他说明都是关于挂起的任务消息。如果你有锁定，你不一定会看到这些。

也就是说，它也提到了sysrq。 sysrq+L可能如果您有的话，这是获取有用信息的另一种方式柔软的锁起来。这将为每个 CPU 生成一个内核回溯。但根本原因可能仅对其中一个 CPU 可见，因此您确实需要能够在那里捕获大量消息。如果你有一个串行控制台那就最好了。如果您有视频控制台，请按 Shift+PageUp可能假设你没有太多的CPU，就可以工作了。

相关内容