如何调试定期停止响应的 CentOS 机器?

如何调试定期停止响应的 CentOS 机器?

我有一台 CentOS 7 机器,每隔几天就会死机一次。 正在kdump service运行,但没有创建崩溃转储文件。
系统日志也没有太大帮助。 例如,在 中/var/log/messages,最近的此类死机发生在第 1091020 行(后面几行是我通过按下电源按钮启动的重启,因为系统在那个阶段没有响应,包括对 ssh 的响应):

1091015 Jun  8 17:20:17 drishti env: 2020-06-09 00:20:17,967 TRACE spool dir at /local/raid0/jsonar/data/gateway/spool
1091016 Jun  8 17:20:17 drishti env: 2020-06-09 00:20:17,968 TRACE spool dir at /local/raid0/jsonar/data/gateway/spool/0
1091017 Jun  8 17:20:17 drishti env: 2020-06-09 00:20:17,968 TRACE spool dir at /local/raid0/jsonar/data/gateway/spool/0/spool
1091018 Jun  8 17:20:17 drishti env: 2020-06-09 00:20:17,968 TRACE spool dir at /local/raid0/jsonar/data/gateway/spool/3
1091019 Jun  8 17:20:17 drishti env: 2020-06-09 00:20:17,968 TRACE spool dir at /local/raid0/jsonar/data/gateway/spool/3/spool
1091020 Jun  8Jun  9 09:17:59 drishti journal: Runtime journal is using 8.0M (max allowed 1.5G, trying to leave 2.3G free of 15.6G available → current limit 1.5G).
1091021 Jun  9 09:17:59 drishti kernel: microcode: microcode updated early to revision 0xca, date = 2019-10-03
1091022 Jun  9 09:17:59 drishti kernel: Initializing cgroup subsys cpuset
1091023 Jun  9 09:17:59 drishti kernel: Initializing cgroup subsys cpu
1091024 Jun  9 09:17:59 drishti kernel: Initializing cgroup subsys cpuacct
1091025 Jun  9 09:17:59 drishti kernel: Linux version 3.10.0-1127.el7.x86_64 ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) ) #1 SMP Tue Mar 31 23:36:51 UTC 2020
1091026 Jun  9 09:17:59 drishti kernel: Command line: BOOT_IMAGE=/vmlinuz-3.10.0-1127.el7.x86_64 root=UUID=c7039987-532d-4b03-b706-0b40b9aa50d4 ro crashkernel=auto rhgb quiet crashkernel=128M
1091027 Jun  9 09:17:59 drishti kernel: e820: BIOS-provided physical RAM map:

您能建议一些方法来调试这个问题吗?

答案1

我假设您使用的是物理计算机,而不是虚拟机 (VM)。这种间歇性故障可能很难诊断。一般来说,您可能遇到软件问题或硬件问题。

硬件

这台电脑的硬件有多旧?即使零件是新的,RAM、CPU、主板或电源中的硬件问题也会导致这种重启。

  • 最简单的检查是 RAM。您需要在计算机上运行 memtest86。以下是一些说明,您需要向下滚动到选项 #2。运行 memtest86 一整夜,或 24 小时,让它有机会进行多次测试。如果没有错误或系统没有重新启动;这意味着您的 RAM 导致问题的可能性很低:但不是零!

  • 电源 (PSU) 是最容易更换的。如果您有备用 PSU,您可以用备用 PSU 替换当前 PSU;或者您可以花钱购买新的 PSU。这里的想法是更换一个组件,但更换它们。一次一个. 这可以隔离可能出错的地方。

  • CPU 温度:有可能您对系统的负荷过重,并且 CPU 温度过高,导致系统重新启动。这些重新启动是否有规律:即当 CPU 正在处理某些事情时?

  • 您是否安装了新硬件?您最近是否在计算机上安装了新设备,例如新显卡?旧机器中的新设备可能会使现有硬件“负担过重”。

    • 例如:您有一个输出功率仅为 400W 的 PSU。它可以正常工作多年,但后来您换了一个需要大量电力的全新显卡。随着时间的推移,您的 PSU 的功率输出会随着老化而下降,而消耗大量电力的新显卡会使 PSU 负担过重,导致电力负载高于 PSU 的承受能力,从而导致这些重启。

软件

  • 如果你能用 USB 盘来控制这台电脑,你可以启动 Live Linux 发行版或类似系统救援 CD 的东西。如果你不需要用电脑来工作,这种方法最有效。然后你让这个系统运行几天,不用改变操作系统。重点是如果你没有硬件故障,系统确实不是如果机器自发重启,则可以断定机器上的软件可能有问题。

  • 一个好的诊断程序是dstat。你想安装它

    • yum install dstat
  • 然后以 root 身份运行它。您可以使用以下命令来
    • dstat -tcdrgilmns --output /var/log/dstat.csv --noupdate 5

从:https://www.rootusers.com/my-top-3-linux-commands-for-logging-problems/

这将使用 -tcdrgilmns 运行 dstat,下面是每个选项的作用 - 请参阅手册页以获取完整信息,因为还有更多选项,请使用您需要的选项。

-t: Time – enables timestamps on the logs, very useful when logging at logs later
-c: CPU stats (system, user, idle, wait, hardware interrupt, software interrupt)
-d: Disk stats (read, write)
-r: I/O request stats (read, write)
-g: Page stats (page in, page out)
-i: Interrupt stats
-l: Load stats (1 minute average, 5 minute average, 15 minute average)
-m: Memory stats (used, buffers, cache, free)
-n: Network stats (received, sent)
-s: Swap stats (used, free) 

--output 指定输出将记录到 /var/log/dstat.csv

--noupdate 意味着 dstat 直到 5 秒后才会刷新,否则 dstat 实际上仍会每 1 秒刷新一次,只是不会写入日志文件。5 还意味着 dstat 查询的结果将每 5 秒记录一次,但通常您可以根据需要更改此设置。

您的目标是将系统统计数据记录dstat到一个文件中,然后在计算机自​​动重启后查看该文件并调查统计数据。RAM 是否已满?CPU 使用率是否过高?请记住,如果没有异常,则可能并不意味着问题不在软件中:只是您没有记录导致问题的原因。

相关内容