单机运维必备：从系统体检到故障排查的Linux命令实战

1. 先说点实话：单机运维根本没有想象中那么简单

前阵子凌晨两点，线上一个单机部署的业务系统突然告警，磁盘使用率99%，服务端口全部无响应。我远程登上去之后，先用df -h看了一眼，再用du -sh /var/log/*定位日志目录，最后journalctl --vacuum-size=200M把系统日志清到可控范围，整个链路不到十分钟。

事后同事说"你那几个命令真熟练"。但说真的，单机运维从来不是"会敲几条命令"这么简单，而是你得知道在什么情况下用哪条命令、命令输出告诉我们什么、下一步往哪查。单机环境没有K8s、没有监控大盘、没有自动扩缩容，所有问题都靠一台机器上的工具链去定位，命令就是唯一的"基础设施"。

很多刚入行的朋友以为单机运维过时了，现在都在上云、上容器、上编排。但实际情况是：大量遗留系统、中小公司内部工具、开发测试环境、边缘节点，依然是单机部署。即便是Kubernetes集群里的Node节点，你登录进去排查问题时，用到的还是这套单机运维命令。所以，单机运维命令不是基本功，而是整个运维体系的地基，地基不牢，后面全是空中楼阁。

这篇东西我不会按命令大全的方式罗列，那种文章你收藏了也不会看。我想按实际排障的思维链路来组织：登机后先做什么、进程怎么管、日志怎么查、网络怎么验、磁盘满了怎么办、文件怎么传、哪些命令容易惹祸。每个部分都结合我实际踩过的坑来写，希望能帮你在真出问题的时候，脑子里有一个清晰的排查地图。

2. 登机第一件事：用一组命令先给机器做"体检"

2.1 uptime和top：先看负载，再看谁在消耗

登录服务器，我习惯先敲uptime，一条命令就能看到当前时间、运行时长、登录用户数和1/5/15分钟的平均负载。

bash复制[root@localhost ~]# uptime
 02:21:33 up 68 days,  4:12,  2 users,  load average: 4.53, 3.21, 2.87

很多人看到load average超过CPU核心数就觉得机器挂了，其实要分场景。如果CPU是4核，负载4.53说明任务队列已经排满，需要进一步看是CPU忙、磁盘IO慢、还是内存不够导致频繁换页。这里有个容易忽略的细节：单机环境里，负载高不一定是CPU问题，也可能是D状态的进程卡在IO上。所以uptime只能给你"生病了"的信号，具体诊断要交给top。

top命令进去之后，按P按CPU排序，按M按内存排序，这是最基本的。我建议你先看%Cpu(s)那行的us、sy、wa三个值：us高是用户态程序消耗CPU，sy高是系统调用频繁，wa高说明IO在拖后腿。如果wa长期超过30%，别急着调应用，先查磁盘IO，iostat -x 1可以看%util和await，%util接近100%说明磁盘基本跑满了。

2.2 free千万别只看第一行，还得理解buff/cache

内存排查用free -h，但新手最容易在这里被误导。看一个典型输出：

bash复制[root@localhost ~]# free -h
              total        used        free      shared  buff/cache   available
Mem:           15G        9.1G        1.2G        128M        5.1G        5.6G
Swap:         2.0G        200M        1.8G

used显示9.1G，free只有1.2G，但available还有5.6G。原因在于Linux会把空闲内存用作buff/cache来加速文件读写，这部分内存在需要时可以随时释放给应用程序。所以判断内存够不够，只看available，不要被used吓到。

Swap的使用情况也需要留意。如果Swap长期有大量占用，同时si和so（swap in/out）数值一直跳动，说明物理内存已经不够用了，系统在频繁换页，性能会出现断崖式下跌。这时候与其调应用参数，不如先看看有没有内存泄漏，ps aux --sort=-%mem | head -10可以快速列出最吃内存的进程。

2.3 df和inode：磁盘满有两种"满法"

磁盘检查我固定用df -h，但这里藏着一个大坑：df -h只显示文件系统容量，不显示inode使用情况。inode是文件系统里保存文件元数据的数据结构，当小文件数量爆炸时，即使还有剩余空间，系统也会报"No space left on device"。

bash复制[root@localhost ~]# df -i /var
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda3      655360 654900  460  100% /var

看到IUse%100%但df -h还有空间时，别发呆，这就是典型的inode耗尽。通常是用find /var -type f | wc -l数一下文件数量，然后定位到某个目录下海量小文件，比如邮件队列（/var/spool/mqueue）、session临时文件、没清理的缓存目录。解决办法要么rm掉无用文件，要么调整文件系统参数或换用支持更多inode的文件系统，但这属于后话。

2.4 journalctl和dmesg：日志是你最靠谱的目击证人

很多系统问题，应用日志不一定全面，但内核日志不会撒谎。dmesg -T可以看到带时间戳的内核日志，硬件报错、OOM（内存溢出）、磁盘IO错误都会记录在这里。比如内存不够时，dmesg里会频繁出现Out of memory: Killed process，这就是真凶。

使用systemd的机器上，journalctl是可以替代/var/log/messages的日志入口。我常用的几条：

bash复制# 查看某段时间的日志
journalctl --since "10 min ago"
# 看某个单元的完整日志
journalctl -u nginx.service
# 看内核日志
journalctl -k