Kdump磁盘大小的最佳实践是什么？

Question

我们有一些 redhat 6 服务器，内存大小约为 64GB，我们计划配置 kdump，但我对应该设置的磁盘大小感到困惑。Redhat 建议设置为 memory + 2% more （即大约需要 ~66GB 的磁盘空间）。我需要您的建议，最好为 kdump 定义多大的磁盘空间。

- Satish

Answer 1

首先，在Redhat支持告诉您之前，请不要启用kdump。 对于大多数Linux“客户”而言，kdump实际上并没有产生任何有用的东西。

其次，kdump可能会将整个RAM内容倾倒到转储文件中。 如果您有64GB的RAM ..AND..在触发kdump时填满了RAM，那么是的，您的kdump文件所需的空间将是RH建议的。 也就是说，大多数问题可以通过部分kdumps来识别。 RH支持甚至曾经建议在将文件发送出去之前对其执行'head -c'以减小其大小。通常将其裁剪到前64MB即可。

最后，在完成故障排除后记得禁用kdumps。 这不是您希望在任何系统上始终运行的东西，除非该系统处于“开发/测试”级别。 最重要的是，在进行kdump后记得清理此空间。

- Jim Black

---

我完全不同意在生产环境中不启用kdump。为了找到意外挂起/重启问题的坚实根本原因，您需要一个vmcore，这是不可妥协的。我始终建议在每个生产和测试系统上启用kdump。您宁愿有一次停机时间启用kdump，还是两次影响客户的停机时间（第一次事故，然后希望再现第二次）。 - cwawak

这取决于您的生产系统的重要性。启用kdump通常不会影响系统性能，但如果系统的内存使用是一个问题，它可能会影响性能，因为它会影响可用内存。更重要的是，在系统创建（通常非常大的）转储文件之前，所需的重新启动可能无法发生。在我的生产环境中，任何意外的挂起/重新启动都通过以下方式处理：1>使用最快的恢复方法（这意味着没有kdumps），2>在最早可能的维护窗口安排完整的硬件交换。 - Jim Black

我不同意你的建议使用“head”来缩小核心。没有人会捕获几个GB的数据仅仅使用前64MB。这个建议可能对于你特定的情况是有效的，但通常使用makedumpfile上的-d1来生成完整的核心是最有用的。对于许多问题，需要这个级别的核心才能得出明确的结论。 - suprjami

Answer 2

我以前也有同样的问题。

可以使用以下方案估算为kdump内核保留的存储器量：

为了保留基本存储器= 128MB
对于每个物理RAM中存在的TB，还需要增加64MB。 因此，例如，如果系统具有1TB的存储器，则将保留192MB（128MB + 64MB）。

因此，我相信对你来说，128MB足够。

您可能希望查看此链接在RHEL6.2（及更高版本）内核上配置crashkernel。

- hereischen

Answer 3

除非系统具有足够的内存，否则kdump崩溃恢复服务将无法运行。有关最低内存要求的信息，请参阅Red Hat Enterprise Linux技术能力和限制比较表中的必需最低值部分。启用kdump时，最低内存要求会增加保留给它的内存量。此值由用户确定，当使用crashkernel=auto选项时，默认为128 MB加上每TB物理内存64 MB（即1 TB物理内存的系统总共为192 MB）。

在Red Hat Enterprise Linux 6中，如果系统具有4 GB或更多的物理内存，crashkernel=auto仅保留内存。

要配置为kdump内核保留的内存量，请以root身份在文本编辑器中打开/boot/grub/grub.conf文件，并将crashkernel=M（或crashkernel=auto）参数添加到内核选项列表中。

- user1263746

---

我需要多少磁盘空间？如果我有64GB的RAM呢？ - Satish