【发布时间】：2013-02-22 01:53:51
【问题描述】：
我们有一个redhat 6 服务器，内存在64GB 左右，我们计划配置kdump，我对应该设置的磁盘大小感到困惑。 Redhat 建议它是memory + 2% more（这意味着大约 66GB 磁盘空间）。我需要您的建议，我应该为 kdump 定义的最佳大小是多少。
【问题讨论】：
标签： linux memory crash-dumps
【发布时间】：2013-02-22 01:53:51
【问题描述】：
首先，除非 Redhat 支持人员告诉您，否则不要启用 kdump。 KDumps 并没有真正产生对大多数 Linux '客户'有用的东西。
其次，kdump 可以（可能）将 RAM 的全部内容转储到转储文件中。如果您有 64GB 的 RAM ..AND.. 在触发 kdump 时它已满，那么是的，您的 kdump 文件的空间将需要 RH 建议的空间。也就是说，大多数问题都可以通过部分 kdump 来识别。 RH 支持之前甚至说过要在发送文件之前对文件执行“head -c”以减小文件大小。通常将其缩减到前 64MB。
最后，请记住在解决问题后禁用 kdump。这不是您希望在任何高于“开发/测试”级别的系统上不断运行的东西。最重要的是记住在 kdump 发生后清理这个空间。
【讨论】：
-
对于在生产环境中不启用 kdump，我完全同意。要找到意外挂起/重启问题的根本原因，您需要一个 vmcore。这是不可协商的，我总是建议在每个生产和测试系统上启用 kdump。您宁愿在启用 kdump 的情况下进行一次停机，还是两次影响客户的停机时间（第一次事件，然后希望重现第二次）。
-
这取决于您的生产系统的重要性。启用 kdump 通常不会影响系统性能，但如果内存使用是系统上的问题，它可以。因为它确实会影响可用内存。更重要的是，在系统创建（通常非常大的）转储文件之前，不会发生所需的重新启动。在我的生产环境中，任何意外挂起/重启都通过以下方式处理：1> 使用最快的恢复方法（这意味着没有 kdumps）和 2> 在尽可能快的维护窗口安排完整的硬件交换。
-
我不同意你用“head”修剪核心的建议。没有人会捕获千兆字节的数据来只使用前 64Mb。该建议可能对 您的特定 案例有效，但一般来说，makedumpfile 上带有
-d1的完整核心是最有用的。对于很多问题，可能需要这一层级的核心才能得出明确的结论。
除非系统有足够的内存，否则 kdump 崩溃恢复服务将无法运行。有关最低内存要求的信息，请参阅 Red Hat Enterprise Linux 技术功能和限制比较表的最低要求部分。启用 kdump 后，最低内存需求会随着为其保留的内存量而增加。此值由用户确定，当使用 crashkernel=auto 选项时，默认为 128 MB 加上每 TB 物理内存 64 MB（即，对于具有 1 TB 物理内存的系统，总共 192 MB )。
在 Red Hat Enterprise Linux 6 中，crashkernel=auto 仅在系统具有 4 GB 或更多物理内存时才保留内存。
要配置为 kdump 内核保留的内存量，请以 root 身份在文本编辑器中打开 /boot/grub/grub.conf 文件，并将 crashkernel=M（或 crashkernel=auto）参数添加到内核选项列表
【讨论】：
-
我需要多少磁盘空间？如果我有 64GB 内存？
我之前也有同样的问题。
为 kdump 内核保留的内存量可以通过以下方案估算：
要保留的基本内存 = 128MB
每个额外增加 64MB 系统中存在 TB 的物理 RAM。 例如，如果一个系统 有 1TB 内存 192MB (128MB + 64MB) 将被保留。
所以我相信 128MB 就足够了。
你可能想看看这个链接Configuring crashkernel on RHEL6.2 (and later) kernels
【讨论】：