机器凌晨三点自己重启了，第二天早上你只收到一条"服务已恢复"的告警，翻遍 /var/log/messages 也找不到一句像样的解释——这种事，干过运维的人多少都碰过。内核 panic 是一件特别"干净"的事故：它不写遗书，不留现场，重启之后进程、堆栈、锁状态全都没了，你只能靠猜。kdump 解决的就是这一件事：在内核死掉的那一刻，把物理内存的现场整机抄一份写到磁盘上，等你睡醒了再来慢慢看。
先把核心判断摆在这里：kdump 不是性能优化项，它一分钱的性能都不会给你；它是「出事后能不能知道发生了什么」的保险费。这笔保险费要付两样东西——一段被永久划走的预留内存，和一块专门用来装转储文件的磁盘。付不付得起、值不值得付，下面几条先记牢：
第一，kdump 只能救内核态，救不了你的程序崩溃。内核 panic 归 kdump 管，用户态进程段错误归 systemd-coredump 管，两条路径完全不相干，混着聊只会越聊越糊涂。
第二，代价是「常驻」的，收益是「概率」的。预留内存从开机那一刻就被划走，无论你一年崩一次还是十年崩一次；而收益只在真出事那天才兑现。
第三，转储能不能成功，跟你预留多少内存几乎一样重要。捕获内核起不来、initramfs 里没带 NVMe 或 RAID 卡驱动、/var/crash 分区塞满——这三类占了我见过的失败案例里的大多数。
第四，vmcore 落下来不等于能复盘。没有对应内核版本的 vmlinux（来自 kernel-debuginfo），vmcore 基本只能看个 log，堆栈和结构体全解不开。
第五，云主机能不能开，不由你决定。部分虚拟化平台不支持 kexec，有些镜像干脆没装 kexec-tools，这事儿得在租之前问清楚，别等出事了才发现。
正常重启走的是 BIOS/UEFI 那一整套：固件上电自检、初始化硬件、再加载操作系统。这条路很稳，但有个致命问题——它会把内存里的一切冲刷干净。等你重新进到系统，崩溃现场早没了。kdump 绕开了这条路径，靠的是一个叫 kexec 的机制：内核 panic 时不走完整的固件重启，而是直接"原地"加载第二个内核，也就是捕获内核（capture kernel），由这个第二内核把崩溃现场的物理内存读出来，写成一个 vmcore 文件。
你可以把它理解成一场接力：第一内核跑到一半突然摔倒，kexec 负责在它摔倒的位置立刻把接力棒塞给第二内核，第二内核不跑业务、不启服务，只干一件事——把第一内核留下的内存当成一块"死掉的物理盘"来读，然后按顺序写进文件。等它写完，机器才会真正重启回正常内核。
捕获内核总得有地方待着。它不能占用第一内核正在用的内存——因为那些内存正是要被转储的证据，踩上去就把现场破坏了。所以做法是在系统启动时，通过内核命令行参数 crashkernel=… 预留一段物理内存，专门留给捕获内核。这段内存在正常运行时不会被分配给任何进程，也不参与伙伴分配器的日常调度，你在 free 命令里看到的可用内存，是已经把它扣掉之后的结果。
关键点在于：这段内存是开机就划走的，不是崩溃时才临时腾出来的。它没有"平时不用、出事再借"这回事。所以预留多少，本质上是在问"我愿意为了让这次崩溃可复盘，长期让出多少内存"。这也是后面讨论"小内存机器值不值得开"的起点。
很多人第一次看到预留值会觉得不可思议：一台 256G 内存的数据库服务器，凭什么第二内核只用几百兆就能把 256G 的内存写完？原因有三层。
第一层，捕获内核不跑业务。它不需要页缓存来加速文件系统，不需要为几千个进程准备内核栈，不需要 slab 缓存里堆着各种业务对象，它只是一个极简的内核加上一个转储工具（makedumpfile）。第二层，它读的是物理内存，不是虚拟地址空间。转储过程本质是"按页框号顺序读物理页、压缩、写盘"，跟原来那套复杂的内存映射无关，不需要重建任何页表结构。第三层，它写盘是流式的，读一批、压一批、写一批，不需要把整个内存镜像先拼在内存里再落盘——那才是真正需要大内存的做法，而 kdump 不这么干。
所以捕获内核的内存需求，主要由"内核本体 + initramfs + 驱动 + 转储工具的工作缓冲区"决定，跟被转储的机器有多大内存基本没关系。这也是为什么预留值可以按内存容量分段给，而不是按内存容量成比例给。
这是一组高频混淆，值得单独拎出来说清楚。你的 Nginx worker 段错误了、你的 Java 进程因为 JNI 崩了，这类是用户态崩溃，由 systemd-coredump 处理，文件落在 /var/lib/systemd/coredump，入口配置写在 /proc/sys/kernel/core_pattern 里。想看这类东西，改的是 core_pattern、ulimit 和 coredumpctl。
kdump 只管内核态 panic——硬件驱动踩了不该踩的地址、自研内核模块解引用了空指针、内核里出现了无法恢复的 BUG_ON。这类崩溃的表现通常不是"某个进程挂了"，而是"整机不动了"或者"整机直接重启"。两者的落盘路径、触发条件、分析工具完全不重叠：配了 systemd-coredump 不等于有 kdump，配了 kdump 也救不了你的应用崩溃。写排查手册的时候别写混，值班的人照着做会白跑一趟。
还有一件事容易漏：看门狗。很多机器挂了硬件看门狗或者平台侧的健康检查，崩溃后几十秒就自动重启。如果 kdump 转储还没写完就被强制重启，盘上什么都不会留下。顺序必须是先转储、后重启，让 kdump 的转储流程走完再触发重启动作，否则你装了 kdump 也只是装了个心理安慰。
先说历史包袱。RHEL 系发行版过去很长一段时间用 crashkernel=auto，意思是"你别管了，系统按机器内存自己算一个值"。这个写法省心，但算出来的值经常偏低，尤其在大内存、加载了大量内核模块、或者 initramfs 比较胖的机器上，捕获内核起不来的概率明显上升。新版本里这个写法已经不再推荐，有些分支直接移除，改成了按内存分段显式指定。
公开文档里常见的分段写法长这样：
crashkernel=1G-4G:192M,4G-64G:256M,64G-1T:512M,1T-:1G
读法很简单，逗号分隔成若干段，每段是"内存区间:预留值"。上面这行翻译过来就是：机器内存在 1G 到 4G 之间时预留 192M，4G 到 64G 之间预留 256M，64G 到 1T 之间预留 512M，超过 1T 预留 1G。这是一份公开文档里常见的分段写法，不要把它当成某个特定版本的唯一默认值——不同发行版、不同内核版本、不同文档里给出的分段值会有出入，用之前先查你自己那套系统的官方文档。
再说代价。对小内存机器，这笔账必须自己算。2G 以内的机器预留 128M 是常见的量级，听起来不多，但放到一台 1G 内存的小 VPS 上，128M 就是可用内存的百分之十几。这百分之十几不是"高峰期才被占用"，是永久消失——你的 PHP-FPM 能开的 worker 数、你的 Redis 能放的数据量，都要按少了 128M 来重新规划。租 1G 内存 VPS 的人，多半本来就是奔着便宜去的，再砍掉一成多内存去换一个"也许一年用不上一次"的转储能力，值不值，得看你跑的是什么。
反过来，在一台 256G 的机器上，按分段规则预留 512M 是可用内存的千分之二，几乎不影响任何事。这就是分段的意义：同样的绝对数值，对不同规模的机器是完全不同的代价，别拿一个固定值套所有机器。
改完参数之后别忘了重建引导配置并重启生效，grub 里改了 crashkernel 但不重新生成配置，重启之后你看到的还是旧值。验证方式也不复杂：看 /proc/cmdline 里有没有你要的参数，再看 kdump 服务的状态是否为 active，两者都对上了才算真的生效。
先给一个最直觉的锚点：不压缩的 vmcore，体积接近物理内存总容量。256G 内存的机器，转出来的原始 vmcore 就是两百多 G 这个量级。原因不复杂——转储就是把物理内存按页写下来，你有多少内存就写多少内容，无论那些页里装的是关键数据结构还是一大片零。
真正决定"要准备多大盘"的，是压缩和丢弃策略。makedumpfile 提供两个维度：压缩算法和丢弃页类型。-l 用 lzo，-c 用 zlib，两者都能把体积压到原体积的几分之一，具体比例随业务内存内容而定——跑数据库的机器内存里塞满了真实数据页，压缩率就低；跑一堆空容器的节点内存里大片是零，压缩率就高，这个倍数写死就是骗人。
第二个维度是 -d 31，它丢弃零页、缓存页、用户态空闲页这几类"复盘时基本用不上"的内容。这是省空间最狠的一刀，也是省时间最狠的一刀：常见情况下能把几十 GB 的原始量级压到几百 MB 到几 GB 这个区间。代价是信息量确实少了——如果你要查的问题恰好跟某个用户态进程的内存内容有关，-d 31 会让你扑空。但对绝大多数内核 panic 场景（驱动踩内存、锁死、内核 BUG），要的只是内核态的堆栈和数据结构，用户态空闲页本来就没什么用。
转储耗时这一头同样现实。大内存机器配机械盘，转储跑几十分钟是常见的事——这几十分钟里机器是不可用的，如果你的业务对可用性敏感，这段时间本身就是成本。启用压缩和 -d 31 的主要动机，一半是省盘，另一半就是省这段时间。它同时也是判断"该不该开"的关键依据：一台 512G 内存、转储盘还是机械盘的机器，开不压缩的 kdump 意味着每次崩溃要额外扛几十分钟不可用，这个代价很多业务扛不住。
| 转储方案 | vmcore 体积量级 | 转储耗时量级 | 需要的磁盘 | 适用内存规模 | 是否推荐 |
|---|---|---|---|---|---|
| 不压缩原始转储 | 接近物理内存总容量 | 最长，大内存配机械盘可达几十分钟 | 至少与物理内存等量，且需留出余量 | 内存较小的机器 | 一般不推荐 |
| -c（zlib）压缩 | 原体积的几分之一 | 中等，压缩耗时高于 lzo | 几百 MB 到几 GB 这个量级 | 中等内存规模 | 推荐 |
| -l（lzo）压缩 | 原体积的几分之一，压缩率通常不及 zlib | 短于 zlib，追求快速落盘 | 几百 MB 到几 GB 这个量级 | 中等及偏大内存 | 推荐 |
| -d 31 丢弃页 + 压缩 | 常见从几十 GB 降到几百 MB 到几 GB | 明显缩短，省时与省盘同时见效 | 同上，且更省 | 大内存机器 | 强烈推荐 |
| ssh / nfs 远程转储 | 取决于所选压缩与丢弃策略 | 受网络与目标端写入速度影响 | 本机无需大转储分区，目标端要有空间 | 本机磁盘紧张的场景 | 有条件推荐 |
| 不开 kdump | 无转储文件 | 无额外停机时间 | 无 | 短生命周期容器节点、内存吃紧小 VPS | 有条件下的取舍 |
落盘位置默认是 /var/crash/<时间戳目录>/vmcore，一个时间戳一个目录，不会互相覆盖，代价是盘会被一次次的转储吃掉，需要自己定留存策略。kdump 配置里也能把目标改成 ssh 或 nfs 远程位置，好处是本机不用留那么大一块转储盘、vmcore 还能集中管理，坏处是转储过程多了一层网络依赖，网络或者目标机出问题，转储就废了。
装完 kdump 不等于能用。我见过太多"服务显示 active，结果真崩了盘上一个字节都没有"的情况。下面四类失败按出现频率排，每类给出症状、确认方法和规避动作。
症状：内核 panic 之后机器直接常规重启，/var/crash 下什么都没有，或者只有个空目录，串口/iLO 里能看到第二内核加载阶段就卡住。
怎么确认：在维护窗口用 echo c > /proc/sysrq-trigger 主动触发一次真实崩溃转储，看能不能正常走完整个流程并生成 vmcore。这一步会真的把机器搞崩，只能在维护窗口做，不要在生产高峰期随手敲。没条件做真实触发的，至少核对 /proc/cmdline 里的预留值，确认它落在该发行版针对你这档内存的建议区间内。
怎么避：别再依赖 crashkernel=auto，改用显式分段语法，并按"内核本体 + initramfs + 驱动"的实际大小留够余量。加载了大量内核模块、用了带特殊驱动的系统，预留值要往上抬。
症状：转储跑到一半中断，目录下留下一个体积明显偏小、或者干脆残缺的 vmcore；系统在转储阶段报空间不足。
怎么确认：看 /var/crash 所在分区的剩余空间，跟"按当前压缩策略算出来的 vmcore 体积"比一比。注意这里比的是剩余空间，不是分区总容量——一个 100G 的 /var 分区被日志和其他数据占到只剩 10G，转储照样失败。
怎么避：给 /var/crash 单独挂一块盘或者单独的分区，别让它跟 /var/log 抢空间；启用压缩与 -d 31 把体积压下来；再配一条留存策略，转储文件按时间或者按份数自动清理，别让历史 vmcore 把盘吃满。
症状：捕获内核起来了，但报找不到转储目标、无法挂载文件系统，或者干脆卡在驱动初始化阶段。
怎么确认：检查 kdump 用的 initramfs 里有没有带磁盘控制器、NVMe、文件系统这几类驱动，以及你的 RAID 卡驱动在不在里面。特殊网卡驱动如果转储目标是 nfs/ssh，也要一并确认。
怎么避：这是最常见的一类失败，尤其是 RAID 卡、NVMe 和特殊网卡驱动缺失。做法是显式把这些驱动模块加进 kdump 的 initramfs 配置里，重建之后再验证一次。装了新硬件、换了 RAID 卡之后，这个 initramfs 也要跟着重建——很多人换完卡就忘了这一茬。
症状：kdump 服务启不来，或者启动时直接报 kexec 相关权限错误，日志里能看到与安全启动、lockdown 相关的拒绝信息。
怎么确认：看固件里安全启动的开关状态，看内核是否运行在 lockdown 模式，再看 kdump 服务启动日志里的具体拒绝原因。
怎么避：要么在固件层调整安全启动策略（前提是你的业务合规要求允许这么做），要么使用经过签名的捕获内核路径。这一条在有合规要求的环境里往往不是技术决定，得先跟安全口对齐再动手。
先说结论：只要是你在独享的物理机或者裸金属上跑重要业务，kdump 默认该开。理由很具体，物理机是你唯一能完全掌控 crashkernel 参数、initramfs 内容和转储目标的环境——想改什么改什么，改完重启验证，没人拦你。而且物理机出内核 panic 的概率和后果都更重：硬件多样性（RAID 卡、NVMe、特殊网卡、自研驱动）意味着驱动踩雷的机会更多，一台机器上跑的业务密度也更高，一次不明原因的重启影响面更大。
尤其这几类机器，收益非常明显：跑自研内核模块的（模块是你写的，出事的概率你心里有数）、用了第三方闭源驱动或者特殊硬件加速卡的、长周期不重启的数据库和存储节点（几个月不重启意味着一旦崩溃连"最后一次变更后出问题"这种线索都没有）。对这类机器，开 kdump 的代价只有几百兆预留内存和一块转储盘，而收益是"下次崩溃能知道是谁干的"，这笔账怎么算都划算。
配置上我的建议是：预留值按分段语法显式写死并留出余量；转储盘单独分区，容量按压缩后的体积量级再留余量；压缩策略直接上 -d 31 配合 -l 或 -c；initramfs 里把磁盘控制器、NVMe、文件系统和 RAID 卡驱动全部显式带上。我给跑自研内核模块的客户配机器时会先把 kdump 打开，一万网络这边的好处是工程师能把 crashkernel 参数和转储目录一并调好，不用你自己反复重启去试参数。
这一节的立场要明确，不搞两头讨好。
云主机：先问平台，再决定。云主机能不能开 kdump，很多时候不由你决定。部分虚拟化平台不支持 kexec，有些镜像里根本没装 kexec-tools，你敲 kdumpctl 只会看到报错。这不是你配置错了，是平台层面就不让做。租之前直接问服务商两件事：这个镜像支不支持 kexec、kexec-tools 装没装。问清楚了再决定要不要在这台机器上跑对可复盘性要求高的业务——如果答案是不支持，你就得接受"内核崩溃只能看到重启记录"这个现实，并据此调整业务架构（比如靠应用层多副本扛住单点崩溃）。
容器节点：短生命周期的不开。如果一个节点上的容器平均活不过几天、节点本身也在频繁扩缩容、业务是 Stateless 的、跑的是标准的、被广泛验证过的内核和驱动，那开 kdump 的收益很低：你真正需要的是"这个节点挂了就换一个"，而不是"搞清楚这个节点的内核为什么挂"。反过来说，长期稳定的存储节点、跑了特殊 CSI 驱动或者自研网络插件的节点，该开还是得开。
小内存 VPS：算清楚那笔账再开。1G 内存的 VPS，按常见量级预留 128M，就是可用内存的百分之十几，永久消失。一台 1G 内存机器通常已经在精打细算——数据库缓存调小、worker 数调少、swap 都开着救急——再砍掉一成多，很可能直接把业务逼到频繁 OOM。而这类机器上跑的业务，多半也没有需要内核级复盘的深度。我的立场是：1G 内存且跑通用 Web 业务的 VPS，不开；把内存留给业务，把可复盘性交给应用层日志和监控。真要开，先确认你拿得到对应内核版本的 debuginfo，否则转储下来也白搭。
vmcore 是一个内存镜像，不是一份报告。想从里面读出东西，需要两样配套：对应内核版本的 vmlinux，以及 crash 工具。vmlinux 来自 kernel-debuginfo 包，路径通常是 /usr/lib/debug/lib/modules/$(uname -r)/vmlinux，命令形如：
crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/.../vmcore
这里有个残酷但必须说的实话：没有 debuginfo，转存下来的 vmcore 基本只能看个 log。内核日志（log 子命令）不需要符号表也能读，所以你至少能看到 panic 前最后几行；但想看调用栈、想解析具体的数据结构、想知道某个锁被谁持有，全都需要 vmlinux 里的符号信息。没有它，你手上就是一个几百 MB 到几 GB 的二进制文件，看不出所以然。
这句实话应该反过来影响你的决策：如果一台机器上你确定拿不到对应版本的 debuginfo（精简镜像、没配 debuginfo 源、内核版本特殊），那 kdump 在这台机器上的价值要打一个极大的折扣，预留内存和转储盘的成本却照付。这类环境，先把 debuginfo 的获取路径打通，再谈要不要开。
装好之后，crash 里几条最常用的命令能给你这些信息：log 看崩溃时的内核日志，这是最快的入口；bt 看崩溃时的调用栈，能定位到具体函数和模块；ps 看崩溃瞬间各进程的状态，尤其是哪些进程卡在不可中断的 D 状态——一堆进程卡在 D 状态往往指向存储或者驱动层面的问题；kmem 之类的命令看内存占用分布，判断是不是内存耗尽或者某个 slab 失控增长。
顺手提醒一句版本对应关系：vmcore 是从哪个内核转出来的，就得用哪个内核的 vmlinux。内核升级之后，旧 vmcore 的符号对不上，要么先别急着清掉旧版本的 debuginfo，要么在留存策略里注明"这批转储需要保留对应版本符号"。
坑一：改了 crashkernel 但没重建引导配置。坑在哪——在 grub 配置里改完参数就以为生效了，重启之后 /proc/cmdline 里还是旧值，kdump 一直用的老预留。怎么避——改完执行配置重建命令，重启后先核对 /proc/cmdline，再确认 kdump 服务状态，两步都过了才算数。
坑二：在生产高峰期随手敲 sysrq 验证。坑在哪——echo c > /proc/sysrq-trigger 会触发一次真实的崩溃转储，机器当场就死，业务当场中断，赶在白天做等于人为制造一次事故。怎么避——只在维护窗口做，提前通知、提前切走流量，把验证当成一次计划内的演练而不是随手一试。
坑三：转储盘和日志盘挤在一个分区。坑在哪——/var/crash 跟 /var/log 共用一个分区，日志涨起来把空间吃光，转储时才发现没地方写。怎么避——给 /var/crash 单独分区或单独一块盘，同时定好留存策略，按时间或份数自动清理历史 vmcore。
坑四：换硬件之后忘了重建 kdump 的 initramfs。坑在哪——换了 RAID 卡、换了 NVMe 盘、加了特殊网卡，正常系统的 initramfs 重建了，kdump 那份没动，捕获内核里还是老驱动，真出事时认不到新硬件。怎么避——把"重建 kdump initramfs"写进硬件变更的操作清单，变更后做一次触发验证。
坑五：看门狗抢在转储之前把机器拉起来了。坑在哪——硬件看门狗或者平台健康检查的超时设得太短，转储还没写完就被强制重启，盘上什么都没留下，你还以为 kdump 坏了。怎么避——确认 kdump 转储流程走完再触发重启，让转储优先；把看门狗的超时跟"最坏情况下的转储耗时"对齐，别拍脑袋定个几十秒。
要，但只能在维护窗口。不验证就不知道 kdump 到底能不能用——服务状态显示 active 只说明配置被加载了，不说明捕获内核能起来、能认到盘、能把文件写完。这三件事里任何一件出问题，平时都看不出来，只有真崩一次才知道。所以我的建议是每台开了 kdump 的机器，至少在上线前或者一次计划内维护窗口里用 echo c > /proc/sysrq-trigger 完整跑一遍，确认 vmcore 真的落在 /var/crash 下、文件大小合理、能用 crash 打开。做完记得把这次验证产生的 vmcore 清掉，别占着盘。
大概率不是你的问题。云主机能不能用 kdump，卡点通常在平台层：部分虚拟化平台根本不支持 kexec，kexec 加载第二个内核这个动作在虚拟化层就被拦掉了；还有些镜像压根没装 kexec-tools，命令都不存在。这两种情况你在实例内部怎么折腾都没用。正确的做法是租之前或者装系统之前，先问服务商两个问题——这个镜像支不支持 kexec、kexec-tools 有没有预装。问清楚了再决定这台机器要不要承载对可复盘性要求高的业务，别等真出事了才发现这台机器天生就没有崩溃现场。
会，而且是永久性的影响。crashkernel 划走的那段内存在开机时就被预留出来，不分配给任何进程，你在 free 里看到的可用内存是扣掉它之后的结果，不存在"平时还能用、出事才让出"这回事。影响多大完全取决于机器总内存：256G 的机器上预留 512M 是千分之二，基本不用管；1G 内存的小 VPS 上预留 128M 就是可用内存的百分之十几，这百分之十几直接决定你能开多少 worker、能给缓存留多少。所以别拿一个固定值套所有机器，小内存机器开之前必须自己把这笔账算一遍。
能删，但别养成"看到就删"的习惯。vmcore 是崩溃现场的唯一副本，删了就再也没有了——机器重启后内存里的一切都没了，无法重采。合理的做法是定一条留存策略：先确认这次崩溃的根因已经定位并且记录进了故障报告，然后按时间（比如保留若干天）或者按份数（比如只留最近几次）自动清理。转储盘容量按"单次压缩后体积 × 计划保留份数"来规划，别让历史 vmcore 把盘吃满导致下一次转储失败。另外，删之前想一想这台机器的 debuginfo 还在不在——vmcore 留着但符号没了，等于白留。
必须转储先、重启后。看门狗（硬件的或者平台侧的健康检查）存在的意义是让机器尽快恢复服务，但如果在 kdump 还没把 vmcore 写完的时候就强制重启，那么这次崩溃就彻底没有任何现场了，你装 kdump 等于白装。所以顺序是：先让 kdump 的转储流程完整走完，再触发重启。具体到配置上，要把看门狗的超时时间跟"最坏情况下的转储耗时"对齐——大内存机器配机械盘，转储跑几十分钟是常事，超时设成几十秒必然抢跑。如果你既想要快速恢复、又想要现场，那就得先靠压缩和 -d 31 把转储耗时压下来。
我的立场是不开。1G 内存的机器按常见量级要预留 128M，这是可用内存的百分之十几，而且是永久划走——这类机器上跑的业务本来就紧巴巴，砍掉一成多很可能直接把应用逼到频繁 OOM，为了一个"也许一年用不上"的转储能力付出这个代价，不划算。更现实的问题是，1G 内存机器通常是精简镜像，你大概率也拿不到对应内核版本的 debuginfo，就算转储成功了也基本只能看个 log，复盘价值极低。真有内核级排查需求，先把业务挪到内存宽裕的机器上，再谈 kdump。
参数这东西别从博客和论坛里抄，抄来的值往往对应的是别人的内核版本和别人的硬件。一手去处有两条：一是内核源码树里 Documentation 目录下的 kdump 相关文档，crashkernel 的分段语法、各参数含义、已知限制都写在那里；二是你所用发行版的官方文档，不同发行版对预留值的建议区间、kdump 配置文件的写法、initramfs 的构建方式都有差异，以你实际跑的那套系统为准。内核版本要一并核对——同一个参数在不同内核版本上的行为和默认值未必一致。
租来的机器上，还有一条路是问服务商。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山总部，自营机柜最快 1 分钟上架，7×24 中文工单平均 5 分钟响应。像"这个镜像支不支持 kexec""kexec-tools 装没装""能不能帮忙把 crashkernel 参数和转储目录调好"这类问题，开工单问清楚比自己反复重启试参数省事得多。硬件故障 10 分钟自动迁移、免费系统盘快照（每日 3 份 / 30 秒回滚）这些能力也能在排查过程中帮上忙——改内核参数之前先打一份快照，试错了能快速回滚，不至于把自己关在门外。工程师还能 1 对 1 协助部署环境，华南、华东、华北、中国香港及海外多节点可选，BGP 多线加 CN2 GIA 回国，具体节点与配置以咨询为准。
装完 kdump 只是把保险买上了，真正决定它有没有用的是后面三件事。第一件是转储成功率——每台开了 kdump 的机器，都应该在维护窗口里真实触发过一次，并且确认 vmcore 能用 crash 打开。没验证过的 kdump 等于没装，这句话一点都不夸张。第二件是留存策略——转储盘多大、保留几份、保留多久、什么时候清，写进运维手册，别让它变成"谁想起来谁去删"。第三件是复盘节奏——vmcore 落下来之后多长时间内必须有人看，看不完的信息（log、bt、D 状态进程、内存分布）怎么沉淀成故障报告，debuginfo 版本怎么跟着内核升级同步管理。这三件事定了，kdump 才是真的在帮你；没定，它就只是一段被白白划走的内存和一个塞满旧文件的目录。
数据来源：文中涉及的 crashkernel 分段取值、预留内存量级、压缩与丢弃页参数、转储路径与工具命令，均为公开文档中常见取值与工程实践经验；实际数值以所用发行版官方文档、具体内核版本以及服务商提供的镜像配置为准。文中提及的服务能力、节点与配置以官网 https://www.idc10000.net/ 实时信息为准，具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
