Linux系统频繁崩溃通常表现为随机重启、内核恐慌（kernel panic）或进程大规模被杀死（OOM）。要从根本上解决，不能只靠重启和重装，而需要建立从崩溃现场采集、原因定位到参数调优的闭环处理流程。本章围绕生产环境最常见的几类崩溃场景，给出可落地的方案。
一、先搞清楚崩溃的类型
在动手改配置前，必须区分崩溃属于哪一类的。内核崩溃（kernel panic）一般会在控制台或日志留下panic字符串，系统直接停止响应；应用层问题引发的挂死，往往表现为某个服务不收请求但系统还能登录；还有一种是OOM Killer触发，内核为保命杀掉占用内存最高的进程，看起来像“莫名服务消失”。
用dmesg和/var/log/messages可以快速分类。如果看到“Out of memory: Kill process”说明是内存策略问题；如果看到“BUG: unable to handle page fault”则多为驱动或内核缺陷。明确类型后，后续手段才有针对性，否则容易在错误方向上浪费时间。
二、用kdump拿到完整现场
很多机器崩溃后只留下一行简略信息，是因为默认没开kdump。kdump能在内核崩溃时启动一个捕获内核，把内存转储写到磁盘。安装并启用后，下次崩溃就会生成/var/crash/下的vmcore文件，这是事后分析的黄金资料。
以CentOS为例，配置过程如下：
# 安装kdump工具 yum install kexec-tools -y # 修改grub预留内存给捕获内核 # 在/etc/default/grub的GRUB_CMDLINE_LINUX后加 crashkernel=auto grub2-mkconfig -o /boot/grub2/grub.cfg # 启用并启动服务 systemctl enable kdump systemctl start kdump # 手动触发测试（仅测试环境） echo c > /proc/sysrq-trigger
拿到vmcore后，用crash工具加载分析。常用命令bt看崩溃时的调用栈，ps看进程状态，能直接定位到出问题的内核函数或驱动模块。没有这一步，多数频繁崩溃只能靠猜。
三、驱动与内核版本的兼容陷阱
第三方硬件驱动是Linux崩溃的高发区。比如某些厂家的网卡、RAID卡驱动未合入主线，每次内核小版本升级都可能引入不兼容。表现为升级后几天内必崩，回退内核就正常。
处理方法是锁定已知稳定内核，并隔离问题驱动。可通过modprobe.blacklist=驱动名临时禁用，或改用主线自带驱动。下面代码展示如何查看当前加载的可疑模块及其版本：
# 列出所有外源驱动（非kernel自带路径） find /lib/modules/$(uname -r)/extra -name '*.ko' 2>/dev/null # 查看某模块信息 modinfo 驱动名 | grep -E 'version|author' # 临时黑名单禁用 echo 'blacklist 驱动名' >> /etc/modprobe.d/blacklist.conf
如果业务必须使用该硬件，应向厂家索取匹配新内核的签名驱动，而不是长期跑在旧内核上，否则又会出现安全补丁无法应用的新麻烦。
四、内存与系统参数调优
即使没有驱动bug，不合理的资源参数也会让系统自我崩溃。比如默认vm.min_free_kbytes太小，高峰期分配不出连续内存就直接panic；又或者没给关键服务设内存上限，一个内存泄漏把全机拖垮。
建议将vm.min_free_kbytes调到物理内存的1%到3%，并保证vm.overcommit_memory按业务特性设置。systemd服务用MemoryMax限制范围，避免单服务吃光资源。参考配置：
# 临时调整保底内存（单位KB） sysctl -w vm.min_free_kbytes=524288 # 写入持久化 echo 'vm.min_free_kbytes=524288' >> /etc/sysctl.conf sysctl -p # 给nginx服务限内存（/etc/systemd/system/nginx.service.d/limit.conf） [Service] MemoryMax=2G
调完后用stress-ng模拟高负载，观察二十四小时是否再崩。若稳定，说明参数生效；若仍崩，则需回到kdump转储找更深原因。
五、建立常态化监控与回归
解决一次崩溃不代表以后不崩。应将kdump、日志采集（如rsyslog转远端）、资源监控（node_exporter）都纳入标准装机模板。每次内核或驱动变更前，先在灰度机跑stress-ng --vm 4 --vm-bytes 80%这类压测，确认无panic再推全量。
只有把排查手段工程化，Linux频繁崩溃才会从救火变成可预防的常规运维项。上述方案覆盖现场抓取、驱动治理、参数调优与持续验证，基本能应对绝大多数生产环境崩溃问题。