主页 / server / 问题 / 1144543
Accepted
Northern Brewer
Asked: 2023-09-27 15:48:44 +0800 CST

许多段错误、RAM 故障？

  • 772

我的 Proxmox 安装不稳定，主机和 LXC 容器都崩溃了。为了找出故障，我尝试交换 RAM、CPU 和 MB。我还进行了全新的重新安装。但我仍然遇到段错误，现在我怀疑我使用的第二组 RAM 棒也有问题。这是因为所有段错误都是由不同的软件库引起的，但 IP/SP 的 RAM 区域大致相同。

但在我出去购买另一对 om RAM 棒之前，我会考虑第二个意见，是 RAM 还是可能是其他原因？

请参阅下面的输出：

-- Boot a7c68ceb88ef4d39af834b30afc8b7a7 --
-- Boot e546636248024201b128732ac8773aa6 --
Sep 11 18:55:30 pve kernel: .NET ThreadPool[3862528]: segfault at 42bfb9a8 ip 00007fe5309a7341 sp 00007fe542bfb8f0 error 4 in memfd:doublemapper (deleted)[7fe530990000+1e7000] likely on CPU 9 (core 16, socket 0)
-- Boot 0d84be2364364002be86b166bab2fb8b --
Sep 17 09:48:27 pve kernel: .NET ThreadPool[516579]: segfault at 7f28aee62de8 ip 00007f28aee62de8 sp 00007ee7357f7728 error 15 in memfd:doublemapper (deleted)[7f28aee60000+10000] likely on CPU 4 (core 8, socket 0)
Sep 17 09:55:45 pve kernel: .NET Server GC[7759]: segfault at 8 ip 00007fd5f7e010bc sp 00007fd5f7f2edf0 error 6 in libcoreclr.so[7fd5f79c2000+4e2000] likely on CPU 4 (core 8, socket 0)
Sep 17 13:50:14 pve kernel: .NET Server GC[1511201]: segfault at 8 ip 00007fb8fe3dfa5b sp 00007fb8fc203970 error 6 in libcoreclr.so[7fb8fdfc4000+4a9000] likely on CPU 4 (core 8, socket 0)
Sep 17 14:36:19 pve kernel: .NET Server GC[548740]: segfault at 8 ip 00007f91c3c010bc sp 00007f91c402adf0 error 6 in libcoreclr.so[7f91c37c2000+4e2000] likely on CPU 8 (core 16, socket 0)
Sep 17 15:09:17 pve kernel: .NET Server GC[1793028]: segfault at 8 ip 00007f885c2010bc sp 00007f885c63adf0 error 6 in libcoreclr.so[7f885bdc2000+4e2000] likely on CPU 4 (core 8, socket 0)
Sep 17 15:11:02 pve kernel: .NET Server GC[1951658]: segfault at 8 ip 00007fc496c010bc sp 00007fc497039df0 error 6 in libcoreclr.so[7fc4967c2000+4e2000] likely on CPU 4 (core 8, socket 0)
Sep 17 15:47:53 pve kernel: PLUGIN[proc][2989]: segfault at b5 ip 00005585edbfb3c2 sp 00007f28d47af4c0 error 4 in netdata[5585edb4e000+270000] likely on CPU 4 (core 8, socket 0)
Sep 17 15:48:16 pve kernel: .NET Server GC[1960959]: segfault at 8 ip 00007f3d5c0010bc sp 00007f3d5c436df0 error 6 in libcoreclr.so[7f3d5bbc2000+4e2000] likely on CPU 4 (core 8, socket 0)
Sep 17 15:50:01 pve kernel: .NET Server GC[2113796]: segfault at 8 ip 00007fd0514010bc sp 00007fd051832df0 error 6 in libcoreclr.so[7fd050fc2000+4e2000] likely on CPU 4 (core 8, socket 0)
Sep 17 16:55:47 pve kernel: .NET Server GC[2121413]: segfault at 8 ip 00007f8b55c010bc sp 00007f8ad404bdf0 error 6 in libcoreclr.so[7f8b557c2000+4e2000] likely on CPU 16 (core 32, socket 0)
Sep 17 18:37:22 pve kernel: .NET Server GC[2396493]: segfault at 8 ip 00007f609c0010bc sp 00007f609c13edf0 error 6 in libcoreclr.so[7f609bbc2000+4e2000] likely on CPU 3 (core 4, socket 0)
Sep 17 18:37:22 pve kernel: .NET Server GC[2396494]: segfault at 4 ip 00007f609be5741b sp 00007f6014e78938 error 4
Sep 17 18:37:22 pve kernel: .NET Server GC[2396495]: segfault at 0 ip 00007f609be5e014 sp 00007f6014df7970 error 4 in libcoreclr.so[7f609bbc2000+4e2000] likely on CPU 8 (core 16, socket 0)
Sep 17 20:15:08 pve kernel: .NET ThreadPool[3291437]: segfault at 7ff4146c5e41 ip 00007ff4146c5e41 sp 00007f75f8edc8e0 error 14 likely on CPU 9 (core 16, socket 0)
Sep 17 21:37:34 pve kernel: .NET Server GC[3577402]: segfault at 8 ip 00007fe8eaa010bc sp 00007fe8eae39df0 error 6 in libcoreclr.so[7fe8ea5c2000+4e2000] likely on CPU 4 (core 8, socket 0)
Sep 18 08:03:31 pve kernel: .NET Server GC[1929138]: segfault at 8 ip 00007f495dfdfa5b sp 00007f495e0efdf0 error 6 in libcoreclr.so[7f495dbc4000+4a9000] likely on CPU 4 (core 8, socket 0)
-- Boot cc5a739fcdde4774baea9476f4e35954 --
-- Boot 37eeab715f514a53a70be19bf02979fb --
Sep 20 10:29:02 pve kernel: traps: .NET BGC[10478] general protection fault ip:7f9f9487a3ad sp:7f5dccff8708 error:0 in libcoreclr.so[7f9f947c2000+4e2000]
Sep 20 16:39:44 pve kernel: .NET Server GC[346393]: segfault at 8 ip 00007fb3534010bc sp 00007fb2d0204df0 error 6 in libcoreclr.so[7fb352fc2000+4e2000] likely on CPU 4 (core 8, socket 0)
Sep 20 16:41:10 pve kernel: .NET Server GC[1951791]: segfault at 8 ip 00007f774ee010bc sp 00007f774f23adf0 error 6 in libcoreclr.so[7f774e9c2000+4e2000] likely on CPU 4 (core 8, socket 0)
-- Boot ee6412c44c104e9eb7464bb4633ffedc --
-- Boot d3ba03c45a0d4a08926f1f6a037c0185 --
Sep 22 06:03:35 pve kernel: postgres[9914]: segfault at 55b789ca6d7b ip 000055b7c4899e43 sp 00007ffd96be1ad0 error 6 in postgres[55b7c45dc000+5d9000] likely on CPU 4 (core 8, socket 0)
Sep 22 08:59:49 pve kernel: unattended-upgr[994014]: segfault at ffffffff00000101 ip 00000000005716be sp 00007ffc3e607990 error 7 in python3.8[423000+296000] likely on CPU 4 (core 8, socket 0)
-- Boot 38a800e306bb414591afb9293bbffa7a --
Sep 25 04:00:15 pve kernel: .NET ThreadPool[2832713]: segfault at 7f04190a5d78 ip 00007f04190a5d78 sp 00007f02a57f7928 error 15 likely on CPU 9 (core 16, socket 0)
Sep 25 16:40:34 pve kernel: postgres[2212459]: segfault at 0 ip 0000000000000000 sp 00007ffc1ad44a78 error 14 in postgres[55cc302e2000+c6000] likely on CPU 4 (core 8, socket 0)
-- Boot 0e3cda8f03d44454a147268b14fd1679 --
Sep 26 12:16:38 pve kernel: .NET ThreadPool[371639]: segfault at 7f8bc9ded288 ip 00007f8bc9ded288 sp 00007f8a915fae40 error 15 likely on CPU 9 (core 16, socket 0)
Sep 26 12:17:03 pve kernel: .NET Tiered Com[409330]: segfault at 7f754c5d42c8 ip 00007f754c5d42c8 sp 00007fb6aabfdcb8 error 15 likely on CPU 9 (core 16, socket 0)
Sep 26 12:29:58 pve kernel: .NET ThreadPool[469166]: segfault at 2f003c ip 00007fcdbd3a098d sp 00007f8b807f4d78 error 4 in libc.so.6[7fcdbd228000+195000] likely on CPU 9 (core 16, socket 0)
Sep 27 04:17:06 pve kernel: .NET ThreadPool[560187]: segfault at 22 ip 0000000000000022 sp 00007f2b00ff6908 error 14 in FinnCore[5567d53cb000+c000] likely on CPU 9 (core 16, socket 0)
Sep 27 05:17:40 pve kernel: traps: .NET ThreadPool[855136] general protection fault ip:7f1c52cb97b8 sp:7f1cb9bfb180 error:0 in libcrypto.so.3[7f1c52cb2000+25d000]
debian

1 个回答

  1. Best Answer

    虚拟内存不是这样工作的。每个进程都有自己的地址空间来存放它们的所有内容，包括指令指针（ip）和堆栈指针（sp）。这更有可能是低级代码中的内存管理问题。虽然并非不可能也有硬件内存故障。

    发生这种情况时获取故障转储并使用 C 调试器查看它们。自然地，libcoreclr.so 库和 .NET cmdline 涉及 .NET 应用程序。显然，微软有具体的建议和工具，请参阅他们的文档：Analyze dumps on Linux。

    配置保存转储文件，如环境变量一样。 例如，看起来很有用DOTNET_DbgEnableMiniDump=1 。 DOTNET_EnableCrashReport=1另请注意，您的操作系统发行版可能有自己的故障转储处理，我不清楚它们如何交互。

    如文档中所示，将故障转储加载到 LLDB 中。 lldb --core <dump-file> <host-program> 然后尝试他们的sos 调试器扩展。像往常一样，当您不熟悉程序时，堆栈跟踪有助于缩小搜索范围。 sos CLRStack 对于托管代码和 sos DumpStack 所有代码。

    收集已安装或与应用程序捆绑的每个 dotnet 运行时的版本信息。安装不同版本并确认是否受影响，例如升级到正在使用的主要版本的最新版本。或者降级到之前可以运行的任何版本。

    Microsoft 声称您可以通过支持渠道获得 .NET 帮助。尽管调试到底发生了什么可能需要对运行时进行黑客攻击的人。一旦您拥有受影响的函数，请考虑通过 Stack Overflow 或 dotnet 问题跟踪器运行它。

    对于不是 dotnet 的崩溃，通过转储，您仍然可以附加像 lldb 这样的调试器。至少回溯是有用的，可以查看代码中是否出现任何模式。

    请注意，软件错误可能是源代码中的错误，也可能是某些内存管理中的错误。或者可能已损坏，您的副本中的某些位被翻转并且它做了坏事。验证已安装软件的完整性。考虑使用完全相同的软件包构建另一个类似的主机，验证存储库的签名，并查看是否可以重现该问题。

    在调查软件故障的同时，您可能希望继续调查硬件故障。

    如果更换内存、CPU和主板后仍然出现故障，要么你没有找到故障部件，要么你是最不幸的人，被运送了新的故障硬件，要么你的物理环境非常恶劣，或者其他原因。这仍然是一个非常广泛的调查，我们从您分享的内容中只能得知一些程序崩溃了。

    RAM 模块不断传输大量数据，且错误率极低。操作系统大部分运行正常但程序有时崩溃的问题很难找到根本原因。内存错误需要 ECC RAM 来确定诊断，并使用它来获取硬件。不幸的是，英特尔和其他公司对他们的产品进行了细分，通常只在服务器盒子上。也许从微型服务器开始，这是一个可以满足各种测试目的的小型塔，首先在具有可靠性功能的不同盒子上重现此故障。

    如果你确实有ECC RAM和其他RAS硬件，当然会有收集和报告故障的软件。在 Linux 上，rasdaemon 是当前流行的工具。

    如果您仍然怀疑它可能是硬件，最终更换所有硬件。在专业场景中，硬件相对于应用程序的下降来说是便宜的。有了这样的服务合同，您就不会因更换零件而引起太多争论。

    特别是电源，更换那个。检查市电的质量，例如使用良好的 UPS。

    所有这些都是很多话，根据您提供的内容可以排除极少数可能的故障。准备好进行深入调查以找出根本原因。

    • 2

相关问题