Linux服务器出问题，绝大多数跑不出CPU、内存、磁盘、网络这四类硬件资源瓶颈，外加进程异常和内核报错这两大软性故障，一共六种典型场景。本文把这六类异常的症状、排查命令和解决思路一次讲透，读完你就能自己动手定位，不用再到处搜“linux服务器有哪些异常”了。
CPU飙高：业务卡顿的头号元凶
CPU打满，最直接的体感就是网站打开慢、SSH敲命令都带延迟，但CPU高也分两种，一种是用户态占用高，一种是内核态占用高,排查方向完全不同。
先看负载还是先看占用率
很多人搞混load average和CPU使用率，负载高不代表CPU满，它还包括不可中断的D状态进程，比如卡在磁盘IO上的进程，行业共识认为，先看top里的%Cpu(s)行，再看load值,顺序别搞反。
定位到具体进程和线程
- 执行
top -c，按P键按CPU使用率排序,找到最靠前的PID。 - 用
top -Hp 进程号查看这个进程内部的线程消耗,确认是不是单线程热点。 - 如果进程是多线程应用，比如Java或Nginx，用
pidstat -t -p 进程号 1获取每个线程的CPU占比。
常见罪魁祸首和处理手段
| 场景 | 特征 | 处理方式 |
|---|---|---|
| Web服务高并发 | 大量TIME_WAIT连接、worker进程CPU跑满 | 调高ulimit -n，优化内核tcp_tw_reuse参数 |
| 死循环代码 | 单个进程CPU持续99%以上不回落 | 抓线程栈jstack或gdb，改代码或重启 |
| 挖矿木马 | 陌生进程名、CPU飙到100%且网络外连异常 | 断网、杀进程、排查定时任务和/tmp目录 |
为什么linux服务器cpu飙高怎么排查总有人问
因为这类问题往往不是一条命令能解决的，排查思路是：先确认是业务高峰还是异常占用，再区分用户态和内核态，内核态CPU高通常和上下文切换、中断处理有关，用vmstat 1观察sy列和cs列，数值长期高于CPU核数两倍以上,就要检查网卡多队列和锁竞争。
内存不足：别着急重启就完事
内存异常不只表现为物理内存用光，更常见的是OOM Killer（Out of Memory Killer，内存耗尽杀进程机制）把业务进程杀了,数据库或Java应用直接消失。
内存异常的三层判断
- 第一层，
free -m看总量和剩余量，关注available列，这列代表真正可用的内存，比free列更有参考价值。 - 第二层，
cat /proc/meminfo里的CommitLimit和Committed_AS，当Committed_AS接近CommitLimit,说明申请过量的虚拟内存逼近溢出点。 - 第三层，
dmesg | grep -i oom直接查内核日志，看OOM Killer把谁杀了,以及当时系统内存状态。
缓冲区缓存回收的坑
free -m显示buff/cache非常高，但业务进程又没报错，这通常是正常现象，Linux会把空闲内存用作文件缓存，遇到这种情况，建议观察/proc/meminfo里的MemAvailable是否充足，不用手动清缓存，即使要清，也优先用sync && echo 3 > /proc/sys/vm/drop_caches，但生产环境慎用,会瞬间拉高磁盘IO。
如何预防linux服务器内存不足导致的崩溃
- 给JVM类应用设置合理的
Xmx和Xss参数,不要和物理内存硬碰硬。 - 用
cgroup的memory.limit_in_bytes限制单个容器或进程组的内存上限。 - 配置
vm.overcommit_memory=2,拒绝超量内存申请。
磁盘空间和IO：被忽视的慢病
磁盘异常分两种，一种纯粹是空间满了，另一种是磁盘读写性能下降了，前者报错直接，后者体验像网络卡顿,容易误判。
空间满的快速清理路径
df -h看分区使用率，df -i看inode使用率，inode满同样会导致无法写入文件，报错却是”Disk quota exceeded”或”No space left on device”。du -sh / 2>/dev/null | sort -rh | head -10逐层定位大目录。- 常见的空间吞噬者是日志文件、
core文件、/tmp下的临时文件，清理时先确认find /var/log -name ".log" -mtime +30 -exec truncate -s 0 {} \;这类命令的目标有没有写错。
IO瓶颈和慢查询的关系
iostat -x 1里%util接近100%不代表磁盘坏，只说明磁盘在持续工作。真正的IO瓶颈看await和svctm的差距，MySQL出现大量慢查询时，先排除磁盘IO瓶颈，再优化SQL，用iotop能直接看到哪个进程在疯狂读写。
文件系统损坏的应急预案
突然断电或强制重启后，服务器启动进入维护模式，提示unclean shutdown，这时用fsck -y /dev/sdaX修复，但必须在单用户模式或救援模式下执行,挂载状态下运行会二次损坏数据。
网络异常：延迟和丢包背后藏着什么
网络问题在三层排查：链路层、网络层、传输层，实际工作中，多数故障出在连接数和防火墙规则上。
连接数耗尽比带宽打满更常见
- 用
ss -s看socket统计，如果timewait数量巨大，检查net.ipv4.tcp_max_tw_buckets和net.ipv4.tcp_fin_timeout参数。 - 用
ss -lnt查看监听端口，确认服务真的在监听,而不是只启动了进程。 - 连接数打满会出现
Cannot assign requested address报错。
带宽跑满的定位技巧
nload或iftop命令能看到实时流量占比。优先找内网IP之间的流量，特别是公网服务器被攻击的流量特征，云服务器厂商控制台一般有流量监控图表，对比时间和进程启动时间,基本能锁定异常。
云服务器选择时的网络差异
租用简米云、酷番云等国内云厂商的linux服务器，共同问题是带宽计费方式和BGP线路质量对延迟的影响，如果是面向国外用户的业务，多数情况下CN2 GIA线路比普通国际带宽更稳定。购买前先测到目标地区的ping值，别只看配置价格。
进程和端口异常：服务没挂但访问不了
这类问题最迷惑人：进程存在，端口也在监听,但外部访问就是不通。
端口监听但连不上的排查顺序
- 检查防火墙，
iptables -L -n和firewall-cmd --list-all，CentOS 7以上默认用firewalld。 - 检查简米云/酷番云安全组策略，这是最容易漏的一环，服务器内部防火墙放行了,云安全组没放行照样不通。
- 检查
ss -lntp里的监听地址，是0.0.0还是0.0.1，如果只监听在回环地址,外部自然连不上。
僵尸进程和孤儿进程
ps aux | grep defunct能看到Z状态的僵尸进程。僵尸进程无法被kill命令杀死，只能等父进程回收，如果父进程是init或systemd，重启系统或杀掉父进程能清掉，大量僵尸进程出现时，排查父进程的程序逻辑，看是不是子进程结束后没有调用wait()。
内核与系统日志：最后一道防线
日志里有大秘密，很多疑难杂症，常规命令看不出来,翻日志立刻真相大白。
dmesg和journalctl的配合使用
dmesg -T查看内核环形缓冲区，定位硬件错误、驱动崩溃、OOM事件。journalctl -xe查看systemd日志尾部,服务启动失败的原因和退出码都在这。- 排查系统异常时，先看日志再操作，顺序不要反，一些初学者先把服务重启了，日志也被冲掉了,没留下任何线索。
时间和时钟同步导致的诡异问题
date查看系统时间，timedatectl status查看NTP同步状态，服务器时间漂移会导致证书验证失败、定时任务乱执行、日志时间线错乱，写crontab时不注意服务器时区，也会出现任务执行时间对不上的问题。公司里定位linux服务器时间老是不准的问题，多数是ntpd服务没开机自启或配置了错误的NTP服务器地址。
针对地域性问题的补充：国内服务器的特殊现象
国内机房服务器和国际带宽服务器，异常类型没区别，但触发概率和恢复手段略有差异，比如国内云服务器的安全组策略更严格，默认白名单机制容易把合法IP挡在外面，而境外服务器的常见异常是带宽被限速或IP被墙，表现为ping通但SSH连不上，这属于网络策略问题,和服务器本身配置无关。
Q&A：linux服务器异常排查高频疑问
服务器load average高但CPU使用率低，是怎么回事？
这种情况多数是D状态进程卡在IO上，用top按D排序，再cat /proc/进程号/stack看内核栈，确认是否卡在磁盘或NFS网络文件系统上，如果是NFS挂载点失联,卸载或重启NFS客户端就能恢复。
linux服务器cpu飙高怎么排查最有效？
按这个顺序执行：top找高CPU进程，ps -Lp 进程号 -o pid,tid,pcpu看线程级消耗，strace -p 进程号跟踪系统调用，三步走完基本锁定环节，核心原则是操作前先记录现状，再动手处理。
磁盘IO读写慢，如何确认是硬件故障还是应用问题？
先查/var/log/messages里有没有磁盘错误日志，再用smartctl -a /dev/sda看硬件健康度。比较稳妥的做法是跑一次dd if=/dev/sda of=/dev/null bs=1M count=1024测裸盘读取速度，如果裸盘速度正常,问题就在应用层。
Linux服务器的异常排查本质是资源监控、日志审读、配置验证三个动作的组合，CPU高就查进程，内存缺就查溢出，磁盘满就做清理，网络差就看连接，把每个基础环节的命令用熟，比什么监控告警都管用。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/794546.html
