服务器一“夯”运维群里往往比过年还热闹业务方急着催恢复开发急着想理由主管急着要结论而你一个人蹲在机房或者盯着远程控制台满脑子只有一个问题——“到底哪一步出了问题”。干运维这些年经手的服务器没有上千台也有几百台我最深的体会是夯机并不可怕可怕的是没有一套顺手、标准、可复现的排查流程。很多兄弟遇到服务器假死第一反应就是重启重启完确实能撑一阵子但下次再夯问题依旧业务方对你的信任也在一次次“重启大法”里被消磨干净。这篇文章就把我日常处理服务器夯机时用的完整排查方案整理出来。从现象分类、现场取证、系统资源排查、硬件健康检查、内核日志分析到网络层的“假夯机”识别全部走一遍。你把它当成自己的排查手册来用遇到问题照着章节翻基本能在最短时间内锁定方向。1. 先把“夯机”分清楚现象分类决定排查方向“服务器夯机”这个词在不同圈子叫法不一样有人叫死机有人叫挂起有人叫假死本质上都是服务器不再按预期响应。但“不再响应”这件事背后的原因天差地别。我一般先把夯机分成三类类别定对了排查方向就对了。1.1 三种典型夯机表现别上来就重启第一类是彻底宕机。电源灯灭、风扇不转、远程连接直接断ping都ping不通。这种问题大多指向硬件主板、电源、内存、CPU少部分是系统引导损坏。处理路径很直接——带外管理面板看状态、进机房看指示灯、备件替换。排查核心是“确认坏件”而不是在那儿敲命令。第二类是假死无响应。服务器电源灯正常、风扇呼呼转但业务进程不响应SSH连不上ping有时候通有时候不通。这类最坑人硬件看起来还活着实际上系统已经卡死或者负载极端异常。常见原因是D状态进程堆积、内存耗尽触发OOM、内核死锁、磁盘I/O卡死后面我会重点讲。第三类是应用层夯住。整机正常ping秒回SSH秒进但某个业务进程CPU飙到100%或者Java应用GC卡死或者数据库连接池被打满导致业务表象跟死机一模一样。这类问题根因通常不在系统层而在应用配置、SQL效率、并发设计上排查时要学会“跳出系统看业务”。1.2 排查前的准备先把“现场”留下来在讲具体排查步骤之前我先说说上现场之前必须准备的东西。很多兄弟一接到告警就冲过去乱敲命令敲完发现系统彻底卡住重启了什么都没留下。我建议至少准备这些一个能访问带外管理系统的通道iDRAC、iLO、IPMI或者KVM远程控制台这样即使SSH断了至少能看到屏幕、能操作控制台。这一步是很多公司没做到位的平时不带外管理IP和密码归档真出事的时候抓瞎。一个记事本或者手机备忘录记录出问题的时间点、最近一次变更发布、扩容、改配置、重启历史。这些信息在后面核对日志时非常关键。如果是物理机确认好机房和机柜位置备好串口线或KVM线确认带外网段能从你当前网络访问。如果你是云服务器准备好云厂商的控制台VNC入口和快照回滚预案。最后送你一句话别慌每一条命令都有目的想清楚再打。慌是排查效率最大的敌人。2. 系统资源层排查CPU、内存、负载的先后顺序系统层资源异常是夯机最常见的原因。十次夯机里起码有六次和负载过高、内存耗尽、D状态进程堆积有关。这个章节我把整个排查顺序和命令用法讲透。2.1 load高不等于CPU高先分清CPU忙还是I/O忙先说load。我见过太多新手一看到load average 80、90就慌了觉得“完了完了服务器要炸”。其实load高不一定等于CPU忙不过来关键是区分是CPU饱和还是I/O等待。很多初学者不知道这个判断方法。你执行uptime和top看load relative到CPU核数的倍数再看CPU那一行的%us/%sy/%wa三个数字。如果%us用户态CPU高说明业务进程在真实计算比如大量编码、压缩、复杂SQL排序。如果%sy内核态CPU高说明系统调用频繁常见于大量小文件读写、网络中断风暴、系统调用死循环。如果%wa很高说明I/O在排队进程大部分时间在等磁盘返回这时候load高其实是磁盘拖的CPU反而是闲的。这招非常关键。因为处理方式完全不一样CPU高你要找是哪个进程在烧CPU考虑扩容、优化代码、限流I/O高你要找哪块盘、哪个文件系统在堵考虑换SSD、调整I/O调度器、优化读写模式。方向搞反了怎么做都是白费。2.2 D状态进程杀不掉的“牛皮糖”怎么处理继续看top的输出你会看到有些进程的状态是D全称是“不可中断睡眠”Uninterruptible Sleep。D状态代表进程正在等待内核I/O返回比如等磁盘读写、等NFS响应、等设备驱动。D状态进程最让人崩溃的地方在于你杀不掉它。kill -9对它无效因为它压根不在用户态内核不处理这个信号。它能做的就两件事等I/O返回然后继续跑或者永远卡在那儿直到系统重启。排查命令top -b -n 1 ps -eo pid,stat,wchan:32,cmd | grep ^ *[0-9]* D cat /proc/loadavg注意wchan列它会告诉你进程卡在内核哪个函数里。比如卡在blkdev_issue_flush就是等磁盘flush完成卡在wait_on_buffer就是等缓冲区I/O卡在nfs_wait_bit就是NFS挂载有问题。这个信息能帮你快速定位是本地磁盘还是网络存储的问题。D状态进程一多系统基本半瘫痪。新进程调度不进来SSH都可能连不上表现形式就跟死机一样。处理路径是先看I/O设备磁盘、RAID卡、存储网络如果I/O没问题再看是不是文件系统卡住最后考虑内核驱动bug。实在等不了就重启但重启前一定用前面命令把现场信息留下来。2.3 内存耗尽与OOM Killer的真凶定位内存撑爆是另一大夯机来源。物理内存耗光、swap又不够的时候Linux内核的OOM Killer会启动开始按分数杀进程。重点来了杀进程只是表象你要回答的问题是“谁把内存吃光的”。排查命令free -h ps aux --sort-%mem | head -20 journalctl -k | grep -i oom grep -i out of memory\|oom-killer /var/log/messages我处理过很多内存OOM的案例发现真正的吃内存大户往往是这几种JVM堆内存被设置成物理机的90%以上高峰期直接爆掉中间件线程池配置过大每个线程占1MB栈空间几百个线程就几百MB还有数据库的buffer pool、连接缓存、排序缓冲叠加起来非常吓人。有人会问Linux的page cache是不是占内存的“元凶”确实你用free看cached那一栏经常很高但这通常是好事——page cache是文件缓存内核会在内存紧张时自动回收。我不建议一看到内存红就去清drop_caches这个操作治标不治本甚至会短暂拖慢性能。先查进程再考虑清缓存。另外提醒一个容易被忽略的点swap的设置。如果swap文件或者swap分区在机械盘上而系统频繁swap内存再叠加磁盘I/O服务器慢到跟死机一样。检查vm.swappiness一般设置为10左右比较合理具体值根据业务定。3. 硬件健康排查磁盘、内存、供电散热的坑如果系统资源层查了一圈D状态进程不多、负载也不高、内存正常但服务器仍然时不时夯死那就要往硬件方向排查了。硬件的坑在于它不一定会主动报错很多时候是“带病工作”到某一天突然彻底趴下表现为周期性、间歇性的夯机。3.1 磁盘是最“阴险”的潜伏者磁盘故障在硬件问题里排名第一因为它太会装了。RAID卡上的盘出现“降级”系统可能还在跑但性能断崖式下跌某块盘开始大量坏道重映射每次I/O碰到坏扇区就卡住表现就是“运行几天就卡死重启又好了”。常用排查命令dmesg | grep -i error\|fail\|timeout\|I/O error | tail -50 cat /proc/mdstat # 软RAID状态 smartctl -a /dev/sda | grep -E Reallocated_Sector|Pending_Sector|UDMA_CRC iostat -dx 1 3 # 看 %util、await、svctmsmartctl是重点。Reallocated_Sector_Ct重映射扇区数只要非0而且持续增长这块盘基本可以判死刑了。Pending_Sector代表有扇区正在等待重映射也是危险信号。UDMA_CRC_Error_Count高一般代表数据线或者背板接触不良。如果用的是硬RAID卡比如MegaRAID、LSI建议直接看卡的日志storcli /c0 show all storcli /c0/e0/s0 show all | grep -E Status|Media Error|Other Error媒体错误和“Other Error”计数器只要非0就说明盘已经出了问题哪怕当前RAID状态还是Online也建议尽快安排备件替换。我见过太多“Online但随时会挂”的盘等到真的挂了再处理业务已经断了一轮。3.2 内存ECC错误与间歇性夯机内存故障我把它排在第二因为它的表现太有迷惑性了稳定运行几个月突然一天夯机重启后又能正常跑。这种“间歇性夯机”很大概率是内存颗粒退化或者ECC纠错机制在频繁“救火”。内存ECC分两类Correctable可纠正和Uncorrectable不可纠正。可纠正错误意味着系统能自己纠错但纠错次数多了说明内存颗粒已经在劣化不可纠正错误一旦出现往往直接宕机或者panic。排查命令grep -i memory error\|ECC\|Corrected /var/log/messages | tail -50 dmidecode -t memory | grep -E Locator|Speed|Part Number很多服务器厂商的带外管理面板iDRAC/iLO里有内存状态页能直接看到每个内存槽的错误计数。出现Uncorrectable错误就直接换条子别扛。出现持续增长的Correctable错误建议也安排更换别等它变成不可纠正的那天。顺带提一句Windows环境。很多Windows服务器蓝屏死机大家第一反应是打补丁、查驱动往往忽略硬件。我之前处理过一台Windows Server频繁强制重启的服务器查来查去最后是两条内存持续报ECC错误跟系统无关。蓝屏和Linux的panic很多时候根因是同一个硬件问题带外管理日志要第一时间看。3.3 温度、电源与降频保护的连环问题散热问题在夯机排查里也很常见尤其在夏天和机柜密度高的机房。常见的链路是这样的机柜风道堵了 → CPU温度过高 → 主板触发降频保护 → 性能暴跌 → 服务超时堆积 → 看起来就像死机。排查要点登录带外管理面板看温度和功率读数确认是否接近告警阈值。执行sensors看各个传感器温度。确认风扇转速有没有fan告警有没有风扇不转。sensors dmesg | grep -i temperature\|thermal还有一个容易被忽略的电源模块冗余失效。双电源服务器如果一路电源坏了负载全压到另一路另一路可能过载尤其在高峰负载时直接保护性断电服务器瞬间崩溃。带外管理面板的电源状态一定要看电源告警日志往往在夯机前就已经存在。液冷服务器的温控策略更复杂一点冷板、泵、冷却液温度都有传感器但排查逻辑一样任何“过热 → 降频 → 卡死”的链路根因都在散热或者电源供给上别在系统层瞎折腾。4. 内核和系统日志所有谜底其实都在里面前面查了资源、查了硬件如果还没锁定问题剩下的答案基本都在日志里。这是排查夯机的最后一道关也是最考验功力的一关。很多兄弟觉得日志多、看不懂其实只要抓住几个关键入口和关键词比瞎猜效率高得多。4.1 dmesg 与内核现场关键词dmesg是内核的日志缓冲区记录了从开机到现在的内核消息。夯机排查里我最关注的是panic、BUG、call trace、I/O error、timeout这几个词。dmesg -T | grep -i panic\|BUG\|warning\|call trace | tail -100 dmesg -T | grep -i error\|fail\|timeout | tail -100很多兄弟不知道dmesg -T这个参数它能把内核日志的时间戳转换成人类可读的时间排查时和系统日志时间线对比特别实用。如果服务器重启过dmesg只会显示本次开机后的消息所以夯机现场的第一手信息最好在刚出问题时就看别等重启完再看那时候很多东西已经丢了。4.2 syslog与journalctl的定位技巧系统日志文件一般存在/var/log/messages或者被systemd的journal接管。我们重装系统后系统日志经常被清空但重启前的历史日志在某些配置下还能保留。排查命令journalctl -xe -n 200 # 最近200条带错误提示 journalctl -p err -n 100 # 只输出错误及以上级别 tail -200 /var/log/messages grep -i error\|fatal\|timeout\|deadlock /var/log/messages | tail -100journalctl -p err这条命令效率很高会把内核、systemd、应用的所有错误一次性列出来比你在几万行日志里翻快得多。注意journal日志默认可能不持久化如果服务器总是重启建议提前配置Storagepersistent否则重启后日志目录可能只剩开机的信息。业务进程的日志也很关键。比如Java应用的gc日志、Tomcat的catalina.out、MySQL的error log、Nginx的error log这些才是判断“应用层夯住”的直接证据。找到业务日志和系统日志的交叉点往往是破案的突破点。4.3 SysRq魔术键系统假死时最后的现场留存如果系统已经假死到SSH进不去、控制台操作卡死还有一个最后的抢救手段——SysRq魔术键。内核预留了一组组合键可以在极端情况下打印系统状态甚至强制重启。前提是内核参数开启了echo 1 /proc/sys/kernel/sysrq # 或者 sysctl -w kernel.sysrq1然后在带外KVM控制台或者物理键盘上按组合键发送命令AltSysRqT打印当前所有任务列表你知道谁在跑就知道谁卡住。AltSysRqM打印内存信息看内存是否耗尽。AltSysRqW打印不可中断/被阻塞的进程状态。AltSysRqS紧急同步所有文件系统尽量保住数据。AltSysRqB强制重启。很多人听到这一套觉得很高端其实它就是内核预留的“后门”。关键在于彻底放弃抢救之前先打一串T、M、W把内核现场留下来。这些输出在重启前会显示在屏幕上拍照或者记录输出对事后定位是救命稻草。5. 网络层“假夯机”服务器活着业务却断了网络故障经常会伪装成服务器夯机。业务方着急地喊“服务器挂了”其实服务器活得好好的CPU、内存、磁盘全正常就是网络收发包出了问题。这种“假夯机”在现场尤其容易误导人所以我把网络排查也放进这套方案里。5.1 连接数、半连接队列与“秒杀式”崩溃最典型的是海量连接把端口或者连接队列打满。我处理过一个秒杀场景应用服务CPU和内存完全正常但用户就是连不上。排查发现nginx的并发连接数到了上限再加上SYN半连接队列被打满新连接握手过程都完成不了表现就和“服务器挂了”一模一样。排查命令ss -lnt ss -st netstat -anp | grep SYN_RECV | wc -l netstat -s | grep -E SYNs to LISTEN|dropss是netstat的现代替代性能更好、输出更全。主要看两个指标一是已建立连接数是否接近somaxconn二是半连接队列SYN_RECV是否满。半连接异常高要么是SYN Flood类流量要么是后端服务响应慢导致大量连接堆积。这时候不能只盯着服务器要结合网关、负载均衡、防火墙的监控一起判断。如果确认是被大量连接打满优先调内核参数tcp_max_syn_backlog、net.ipv4.tcp_syncookies但本质还是要看后端为什么处理不过来——是线程池太小SQL太慢还是下游依赖超时。连接数只是症状后端容量才是根因。5.2 网卡丢包与协商异常看起来像死机网卡物理损坏、驱动bug、固件问题也可能造成“看似死机”的假象。网卡如果进入了异常状态收包不处理、发包发不出去应用层自然全挂但系统负载看着不高——因为问题发生在数据链路层CPU根本感知不到。排查命令ip -s link ethtool eth0 ethtool -S eth0 | grep -i err\|drop重点关注几个计数器rx_error、rx_dropped、tx_timeout、tx_dropped。如果tx_timeout持续递增网卡基本已经“半死”状态常见于老旧网卡驱动兼容性问题或者网线/模块光衰过大。rx_dropped高也可能是接收队列溢出或者防火墙drop需要进一步看ethtool -S的详细分类。很多Linux发行版默认没有ethtool需要提前装好。这就是平时运维的“弹药储备”价值等夯机了再装机已经来不及了。6. 高频原因速查表与两个实战复盘这部分我把自己历年处理过的夯机案例提炼成一张速查表再单独复盘两个印象最深的案例。你遇到问题可以先对着表自查比自己从零摸索快得多。6.1 夯机原因对照表直接对照排查现象特征可疑方向首选命令/操作load高、%wa高、D状态进程多磁盘I/O瓶颈iostat -dx 1ps -eo pid,stat,wchan内存持续升高、OOM杀进程JVM/页缓存/swap不足free -hps按%mem排序journalctl查oom偶发重启、温度告警散热/电源/内存ECCsensors带外管理日志smartctl网络全断、业务连不上但系统正常连接数/网卡故障ss -lntethtool -Snetstat半连接数卡在内核某函数、间歇性panic内核bug/驱动问题dmesg抓call trace升级固件驱动应用假死但系统健康应用线程池/GC/后端依赖业务日志jstack数据库慢查询日志这张表不是我编出来的是这些年真金白银踩出来的。每个方向背后都有案例比如“内存持续升高”那条我处理过三次都是JVM堆配置过大导致的“偶发重启加温度告警”那条几乎每次都指向机房机柜的散热盲区。6.2 两个真实案例间歇性重启背后的真凶有一个案例我记得特别清楚。某天凌晨2点公司一台数据库服务器夯死所有连接超时重启之后能正常用但过一两天又夯一次。第一次排查我以为是磁盘I/O问题因为夯机时iostat显示util很高。结果重启后我重新检查发现每次夯机前/var/log/messages里都有一条/dev/sda: I/O error紧接着是SCSI层的port reset。最后用smartctl -a一查盘上Reallocated_Sector_Ct已经到几千了坏道重映射导致每次I/O访问到坏扇区区域就卡住。换掉那块盘后问题彻底消失。这个案例给的最大的教训是间歇性夯机一定要看smartctl不要迷信“重启就好”。临时重启维持业务没问题但根因不挖出来下一次夯机只是时间问题。另一个案例是Windows服务器。戴尔R750xs跑Windows Server 2012R2总在夜间跑批任务时蓝屏死机。运维和开发互相甩锅了好几次最后我坚持查带外iDRAC日志发现两条内存条报Correctable ECC错误持续增长最后触发Uncorrectable直接蓝屏。拔掉故障条子、更换新内存后跑批任务再也没崩过。这个故事告诉我跨平台排查时带外管理日志是统一的突破口。不管是Linux还是Windows硬件告警信息都在带外系统里别只在操作系统里打转。写在最后的几句实在话最后分享几条自己踩过坑换来的体会算不上什么高深理论但都是实打实的运维经验。第一夯机排查最忌讳“重装解决法”。不要一出问题就重启、重装、重置先把现场信息留住。系统日志、内核日志、带外管理日志这三样是排查的根本。没有现场信息再厉害的技术也没法定位根因。第二时间同步是容易被低估的基础设施。服务器时区和时间不同步会导致多台服务器日志时间线对不上排查集群夯机时恨不得砸键盘。把NTP或者chrony配置好让所有服务器的时间保持一致排查效率能提升一个档次。第三真正优秀的运维不是等夯机了才排查而是平时就把监控、日志、带外管理工单这些准备做好。我给自己定的目标是服务器夯机后10分钟内给出初步方向30分钟内定位到具体原因。这个目标靠的不光是技术积累更是流程成熟和工具完备。希望这份排查方案能帮你在下次遇到服务器夯机的时候少走点弯路少熬几个夜。毕竟运维这行最重要的不是“我能修”而是“我能快准狠地修好”。