我有一个不稳定的 Proxmox 安装，主机和 LXC 容器都崩溃了。为了找到故障，我尝试交换 RAM、CPU 和 MB。我还重新安装了。但我仍然遇到段错误，现在我怀疑我使用的第二组 RAM 棒也有故障。这是因为所有段错误都是由不同的 SW 库引起的，但 IP/SP 位于大约相同的 RAM 区域。
但在我出去购买另一对 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]
答案1
虚拟内存不是那样工作的。每个进程都有自己的地址空间，用于存放所有东西，包括指令指针 (ip) 和堆栈指针 (sp)。这更有可能是低级代码中的内存管理问题。尽管也有可能出现硬件内存故障。
发生这种情况时获取崩溃转储并使用 C 调试器查看它们。从 libcoreclr.so 库和 .NET cmdline .NET 应用程序自然参与其中。显然，微软有具体的建议和工具，请参阅他们的文档分析 Linux 上的转储。
配置保存转储文件，例如环境变量.DOTNET_DbgEnableMiniDump=1 并且 DOTNET_EnableCrashReport=1 看起来很有用。还要注意，你的操作系统发行版可能有自己的崩溃转储处理，我不清楚它们如何交互。
按照文档所述将崩溃转储加载到 LLDB。 lldb --core <dump-file> <host-program> 然后尝试sos 调试器扩展. 通常，当您不熟悉某个程序时，堆栈跟踪有助于缩小搜索范围。 sos CLRStack 针对托管代码和 sos DumpStack 所有代码。
收集已安装或与应用程序捆绑的每个 dotnet 运行时的版本信息。安装不同的版本并确认它们是否受到影响，例如升级到正在使用的最新版本。或者降级到之前可以运行的任何版本。
微软声称你可以通过以下方式获得.NET 帮助支持渠道。尽管调试到底发生了什么可能需要有人对运行时进行破解。一旦您拥有受影响的函数，请考虑通过 Stack Overflow 或 dotnet 问题跟踪器运行它。
对于非 dotnet 崩溃，使用转储仍然可以附加 lldb 等调试器。至少回溯会很有用，可以查看代码中是否出现了任何模式。
请注意，软件故障可能存在于源代码中，也可能是某些内存管理中的错误。或者可能是损坏的，您的副本中的某些位被翻转，并且正在做坏事。验证已安装软件的完整性。考虑使用完全相同的软件包构建另一个这样的主机，验证存储库的签名，看看您是否可以重现该问题。
在调查软件故障的同时，您可能希望继续调查硬件故障。
如果更换内存、CPU 和主板后仍然出现故障，要么是您没有找到故障组件，要么您是最不幸的人，收到了新的故障硬件，要么您的物理环境非常恶劣，要么是其他原因。这仍然是一个非常广泛的调查，从您分享的内容中我们只能知道某些程序崩溃了。
RAM 模块不断传输大量数据，错误率极低。操作系统大部分时间运行正常但程序有时会崩溃的问题很难找到根本原因。内存错误需要 ECC RAM 才能准确诊断，并获取硬件。不幸的是，英特尔和其他公司对其产品进行细分，通常只在服务器机箱上进行。也许可以从微型服务器开始，这是一种可以用于各种测试目的的小型服务器，首先在具有可靠性功能的不同机箱上重现此故障。
如果你确实有 ECC RAM 和其他 RAS 硬件，当然会有软件来收集和报告故障。在 Linux 上，rasdaemon 是当前流行的工具。
如果您仍然怀疑可能是硬件问题，请最终更换所有硬件。在专业场景中，相对于应用程序故障，硬件价格便宜。有了这样的服务合同，您在更换零件方面就不会有太多争论。
尤其是电源，请更换它。检查市电质量，例如使用良好的 UPS。
以上这些只是说说而已，根据您提供的信息，很少能排除可能的故障。做好深入调查以找出根本原因的准备。