企业官网建设流程全解析

简介：面向Linux系统管理员与运维工程师的故障排查资料，聚焦系统死机或崩溃后的信息收集与原因定位，分别讲解Core dump、Diskdump和Netdump三种机制。文档对每种方法均给出适用场景与完整配置流程：Core dump用于捕获应用程序崩溃时的内存状态，可通过ulimit与core_name_format设置转储路径；Diskdump适用于单机内核崩溃场景，涉及保留分区初始化、initrd重建及HP SCSI设备模块替换；Netdump则可在不支持Diskdump的版本中将崩溃信息推送至远程服务器，并附有服务端与客户端的详细配置步骤。除原理外，还包含网卡netpoll支持性判断等排错细节，能帮助读者快速搭建崩溃信息收集环境，区分硬件故障还是应用程序bug，从而制定针对性修复方案。资源共1个doc文件，压缩包约47KB，内容精炼，目前已有526人学习。适合需要掌握Linux崩溃转储配置、提升系统稳定性的运维人员参考。 Linux服务器一旦“死机”，整个运维群能在三分钟内从安静到炸锅。业务告警、客户电话、领导追问全堆过来，而你面前只有一台卡死的终端。我做过几年一线运维，碰到过不少Linux挂起、无响应甚至kernel panic的现场，老实说，真正“救不回来”的情况少，更多时候是假死——系统还活着，只是没办法正常对外服务了。这篇把我自己的处理套路整理出来，包含快速判断、原因定位、徒手救场、事后加固几个部分，适合正在被服务器卡死折磨的运维、刚接触Linux想建立排查思路的同学，以及所有被“死机”两个字吓到过的人。里面涉及的排查命令和处置手段，我在生产环境里都实测过，照着走能少踩很多坑。

1. 先搞清楚：这是真死机还是假死机？

很多人一看到页面打不开、SSH连不上，就急着去云控制台强制重启。我劝你先别动手，因为强制重启会把内存里没落盘的缓存、日志和临时状态全部丢掉，万一后面要分析现场，连线索都没了。处理死机的第一步不是救机器，而是判断它到底处于什么状态。

1.1 三类常见的“死机”现象

按我自己的经验，Linux下被叫做“死机”的情况，大致可以分成三类。

第一类是“网络假死”。进程还在跑，CPU还在计算，但因为网络栈异常、网卡驱动忙、防火墙规则误封等原因，外部完全连不上这台机器。表现就是ping不通、SSH超时，但通过物理控制台或者带外管理（服务器的BMC/IPMI，云上的VNC控制台）切进去，发现系统其实还在正常运行，top、ps都还能用。

第二类是“资源耗尽型假死”。内存被吃满、磁盘被写满、CPU长时间跑在100%，这时候系统会明显卡顿，SSH能建立连接但敲命令半天没反应。这种情况最迷惑人，表面看像死机，实际是虚拟内存疯狂换页、进程进入不可中断睡眠状态堆积，系统在“慢性窒息”。

第三类是真正的“内核级死机”。比如kernel panic，屏幕上一堆调用栈，键盘灯无响应；或者系统完全黑屏断电；再比如硬件故障触发的宕机。这种时候基本只能靠物理手段或带外管理重启，系统内已经没有操作空间了。

1.2 三分钟快速判断的思路

遇到疑似死机，我一般按下面这个顺序快速摸底：

1. 先看SSH能不能连上。能连上就说明系统还没死透，马上用top看Load Average和CPU/内存占用。
2. SSH连不上，就用带外管理或云厂商的VNC控制台再试一次。能切进去，说明内核还活着，问题出在网络或服务层面。
3. 控制台也进不去，或者进去以后键盘完全没响应，再看服务器电源灯、面板报错信息，判断是硬件故障还是内核崩溃。

这套流程的核心逻辑是，先分清楚问题出在网络、资源还是内核/硬件层。不同层面的处理手段完全不同，上来就重启是碰运气，不是处理故障。

2. 死机背后的常见原因拆解

判断完“死没死透”，下一步就是定位“为什么死”。我把这几年见过的高频原因整理了一下，基本逃不出资源、内核、硬件这三类。

2.1 资源耗尽型：内存、磁盘、CPU

内存耗尽是最常见的原因。Linux有个OOM Killer机制，当内存耗尽时内核会主动挑进程杀掉，有时候杀的是无关业务进程，引发大面积故障，有时候连关键进程都保不住，系统看起来就像冻住了。排查时我会先用free -m看available，再看dmesg | grep -i oom或者直接翻journalctl，OOM Killer到底杀了谁，日志里写得清清楚楚。

磁盘满也会造成“假死”效果。尤其是根分区满，会导致很多依赖临时文件、落盘的进程卡住，系统响应极慢。这里要提醒一个很多人踩过的坑：只看df -h不够，有时候是inode满了，df -h显示空间还有剩余，但df -i会告诉你inode已经100%占用，照样写不了文件。

CPU满载通常不会直接“死机”，但如果单核被某个死循环进程占满，而你的应用又是单线程依赖，表现也会接近卡死。Load Average高到CPU核数的好几倍时，系统调度出现严重排队，连SSH敲个ls都可能等好几秒。

2.2 内核级故障：panic、死锁、OOM连锁

我遇到过最让人头大的是内核死锁和Kernel Panic。Kernel Panic的特征非常明显：屏幕上一堆调用栈，最后一行是Kernel panic - not syncing，系统基本无法自动恢复。死锁更隐蔽，某个内核线程因为资源争用卡死在临界区，CPU占用看起来不高，但系统整体无响应。这类问题靠敲普通命令救不回来，需要结合kdump、crash工具做内核转储分析，那是比较进阶的领域。日常处理时首要目标往往是快速重启恢复业务，同时尽量保留现场证据，比如控制台截图、串口日志，别等重启完才后悔没留档。

2.3 硬件与驱动，以及虚拟化环境的特殊情况

硬件层面的坑也很实。内存条出现ECC错误、硬盘出现大量坏道或SMART告警、网卡或SSD的固件Bug，都可能直接引发死机。服务器宕机后，建议第一时间看带外管理里的硬件日志，很多服务器会在开机自检时报告硬件告警，这比你在系统里盲猜要靠谱得多。

还有一个容易被忽略的场景：虚拟机。在VMware或KVM里跑的Linux，“死机”很可能是宿主机层面出的问题。比如VMware报“客户机操作系统已禁用CPU，请关闭或重置虚拟机”，就是虚拟机内部无法正常获得CPU资源时出现的典型情况，本质是Hypervisor和Guest之间的状态异常。宿主机内存超分、CPU过载、VM Tools失效，都可能让虚拟机内部突然卡死。所以虚拟机“死机”时，先看一眼宿主机负载，往往比在虚拟机里翻日志更快找到问题。

3. 徒手排查的核心命令与实操

系统还能进去，或者通过控制台能进去，就要抓紧时间在“窗口期”里收集信息。下面这几个命令是我的固定动作，按顺序跑基本不会漏。

3.1 第一反应：这几条命令先跑起来

我先跑uptime，看系统运行时间和Load Average。Load Average的三个数字分别是1分钟、5分钟、15分钟的平均负载，如果1分钟远大于15分钟，说明负载是最近突然涨起来的；再结合CPU核数判断，比如8核机器Load到了16甚至32，基本已经过载到不行了。

然后是free -m，重点不是看total，而是看available。available才是近期真正可用的内存量，它已经扣掉了buff/cache里不能回收的部分，这个值掉到几百MB甚至几十MB，就已经到了很危险的地步。再配合top按内存或CPU排个序，直接按大写M按内存排序、大写P按CPU排序，立刻看谁在吃资源。顺手看一眼vmstat 1 3，第一行是平均值，后面两行是最近1秒的实际值，r列表示正在运行的进程数，多数时候大于CPU核数，就说明任务排队排不完了。

3.2 日志怎么查最有效率

死机现场的日志是破案关键，但别在日志里大海捞针。我一般按这个路径来：

先敲dmesg -T，把所有内核日志带时间戳从头扫一遍，重点看有没有Out of memory、Killed process、panic、BUG: soft lockup这些关键字。然后是journalctl --since "10 minutes ago"，把最近十分钟的系统日志拉出来，过滤同类错误。如果系统连日志服务都没起来，就直接看/var/log/messages或/var/log/syslog。

还有一个容易被忽略的事：等系统勉强恢复或重启后，第一时间把日志备份走，用journalctl --since "今天" > /tmp/fault.log把现场留存下来。别等一切恢复后才想起查日志，结果记录早被日志轮转覆盖了。

3.3 利用SysRq键实现“软重启式”救场

Linux内核里藏着一套专门用来应急的SysRq机制，可以理解为“让内核在按了特殊组合键后执行紧急命令”。机房服务器一般没有键盘，但只要还有控制台，或者能写/proc/sysrq-trigger，照样能用。先把/proc/sys/kernel/sysrq设为1，再通过echo向/proc/sysrq-trigger写入字母触发。

最常用的救命组合是REISUB，对应R、E、I、S、U、B六个字母：

• R：unraw，恢复键盘模式，控制台还能操作时先用它。
• E：terminate，给所有进程发SIGTERM，让它们尝试正常退出。
• I：kill，给所有进程发SIGKILL，强制杀掉。
• S：sync，把内存数据强制同步到磁盘。
• U：remount-read-only，把文件系统重新挂载为只读，避免数据继续写入损坏。
• B：reboot，重启系统。

这套操作比拔电源或强制断电温和得多，能大幅降低文件系统损坏概率。在高可用集群里，个体服务器重启后业务自动切换，应用层抖动也能控制在较小范围。

4. 从一次真实故障看完整处理流程

理论讲再多，不如把一次完整的处理过程拆开来看。我之前处理过一起半夜告警的典型场景，按时间线记下来，几乎覆盖了能踩到的所有坑。

4.1 故障现象与初步判断

某台8核16G的服务器，凌晨2点左右突然告警，业务接口全部超时。我先试着SSH登录，敲完密码回车，卡了十几秒才出现命令行提示符，执行top又一直等待输出。我切到VNC控制台，明显感觉响应迟缓，说明系统还活着，但负载非常高，基本可以排除网络假死和完全宕机，锁定为资源耗尽型假死。

然后在控制台里执行uptime，等了差不多半分钟，屏幕才回显。Load Average已经超过48，而机器只有8个核，相当于平均每个核排队近6个任务，系统调度严重阻塞。接着看free -m，available不到200MB，swap使用率超过90%，内存已经被耗到极限。

4.2 逐步定位与处理

用dmesg查日志，很快看到大量Out of memory的记录，以及Killed process的字样。让我哭笑不得的是，被杀掉的进程里不仅有临时任务，还有一个数据库的监控agent。再用top按内存排序，发现罪魁祸首是一个JVM进程，堆内存配置高达12G，而整台机器才16G，叠加其他进程直接顶穿内存。

处理思路开始清晰：先把关键业务进程护住，再对JVM做临时调整。我给关键进程调整了OOM Score，效果有限，最后和业务方确认后，临时停掉了一个非核心的批处理任务，释放出内存空间，系统才慢慢缓过来。等白天业务低峰期，我把JVM堆参数从12G调到8G，同时给数据库agent进程设置了OOMScoreAdjust，让OOM Killer在极端情况下优先杀低优先级进程，不再误伤核心组件。

4.3 事后加固与预防

这件事之后，我给这批服务器做了一套组合拳：一是部署了内存和磁盘使用率的监控告警，内存可用量低于1G就告警，磁盘使用率到80%就预警；二是把所有核心进程都设置了OOMScoreAdjust，让核心服务在OOM时成为最后被杀的对象；三是用logrotate保证系统日志不会因为单日故障刷爆磁盘；四是给云主机开启了kdump内核转储，确保再遇到panic时有核心转储可分析。

这套组合拳打下来，这类问题基本没再复发。Linux死机处理，真正值钱的地方往往不在“救火”，而在火灭之后的“防火”。

5. 常见问题与排障速查表

把我这些年最常被问到的问题、以及最容易踩的坑整理成一张速查表，遇到类似情况可以直接对照。

另外有几个我反复踩过的坑，想单独拎出来说。

第一，不要动不动就kill -9。对于内存不足，先考虑释放缓存sync && echo 3 > /proc/sys/vm/drop_caches，再排查业务本身，而不是一遍遍杀进程，杀到最后连操作系统都没法正常响应。

第二，drop_caches这种清理缓存的操作用在测试环境没问题，生产环境要慎之又慎。别为了“清缓存”把还没落盘的脏数据搞丢，一旦写在文件系统缓存里的数据被清理，运气不好就是文件损坏。

第三，遇到虚拟机死机，先在宿主机侧确认负载和资源状况再决定重启时机。直接强制重置，有时候会把文件系统搞出问题，重启后还要跑fsck，更加折腾。

第四，平时要做好应急演练。我比较常用的做法是，在测试环境故意制造一次内存耗尽，让团队成员从头到尾走一遍排查和处置流程，熟手带新手。真正出生产事故的时候，大家才不会手忙脚乱。

我在实际处理中最大的体会是：Linux死机这件事，处理多了你会发现，真正重要的不是某一个命令，而是稳定的排查顺序、冷静的现场判断，以及事后愿意花时间补全的监控和加固。每次故障都值得复盘，控制台截图留档、日志备份保留、处理过程记录下来，几次以后你就能形成自己的应急预案。这个方法不管是用在CentOS、Ubuntu还是国产发行版上，逻辑都通用。下次再遇到卡死的机器，至少有章可循，不再全凭手气。

本文还有配套的精品资源，点击获取