1. 先搞懂系统管理的排查逻辑命令是手段定位问题是目的干运维和系统管理这行绕不开的就是一堆系统管理命令。不少刚入行的朋友来找我聊第一句话往往是“Linux命令太多了根本记不住怎么办”。我的回答一直很直接别去背命令去背思路。命令只是个工具真正值钱的是你拿到一台机器时知道从哪儿下手、每一步在验证什么。只要思路清晰命令选项记不全说白了一眼man手册的事但反过来就算命令背得滚瓜烂熟机器一有问题就乱敲一通那跟拿着扳手不知道修哪儿没区别。这篇东西不是照着手册把Linux系统管理命令念一遍那没意义。我想聊的是实际干活的时候那些你每天都会碰到的场景CPU飙高了怎么办、磁盘满了但是删了文件空间没回来、机器莫名其妙卡顿、端口起不来、日志刷得飞快等等。每个场景我会把用到的核心命令、怎么看输出、判断逻辑是什么、常见的坑是什么一次性说透。适合刚接触Linux服务器管理的同学也适合那些用了一段时间但总觉得差点章法的人。看完之后你至少能拿到一个属于自己的排查套路而不是再靠运气修机器。我自己平时工作里有个习惯无论什么问题先用一个一分钟的快速体检脚本定位方向再针对方向深挖。这个习惯帮我省了非常多的无效操作。日常的体检其实就四类指标负载load average、CPU使用率、内存和Swap、磁盘和IO。后面所有命令的组合本质上都是这四类的延伸。先把大方向拿准再决定用哪个Linux系统管理命令去追细节效率比上来就抓着一堆工具乱试高得多。2. 进程管理系统卡不卡先看谁在吃资源2.1 top和ps的正确用法CPU高和IO高要分清Linux系统管理命令里用得多也容易误判的就是进程查看这组。很多同学一看到机器卡第一反应就是用 top 敲一下瞄一眼 %CPU 最高的那个进程就觉得找到元凶了。这个习惯我建议改一下因为CPU高和IO高在 top 里长得不一样而且痛点完全不同。先看 top 最顶上那几行统计信息。load average 有三个数字分别代表1分钟、5分钟、15分钟的平均负载。这里有个极其常见的误区负载高不等于CPU忙。负载衡量的是处于可运行状态和不可中断睡眠状态的进程数。不可中断睡眠状态通常就是等IO。所以当你看到 load average 飙到四五十甚至上百但 %Cpu(s) 这行的 us 占比并不高反倒 wa 也就是 iowait 很高说明IO才是瓶颈。这时候按 x 键加高亮按 b 键加粗能看到当前排序的列。P键按CPU排序M键按内存排序。当你确定是CPU瓶颈时重点看 %CPU 列。但注意了top 里的 %CPU 默认是进程自启动以来总的CPU时间占用的平均值不是瞬时的。所以一个进程如果之前吃得猛现在早不忙了它照样会排在最上面误导你。遇到这种情况我习惯按一下 shift i 切换成 irix 模式关掉或者干脆用 top -p 盯具体PID再配合 top -H -p PID 看这个进程内部哪个线程在吃资源这是排查多线程服务CPU飙升的标准操作。ps 这命令在Shell脚本里比交互式的 top 用得多。平时排查我常用的组合是 ps -eo pid,ppid,user,%cpu,%mem,rss,vsz,stat,etime,cmd --sort-%cpu。这里解释几个容易忽略的字段。RSS是物理内存占用单位是KBVSZ是虚拟内存很多同学看VSZ大就觉得内存泄漏其实虚拟内存大很正常重点盯RSS。STAT这列的值建议背下来R是运行S是睡眠D是不可中断睡眠Z是僵尸。其中D状态的进程多见于IO等待Z状态说明父进程没好好回收子进程处理不好会累积成内存泄漏。2.2 排查进程的实战细节环境变量、启动目录和端口对应关系进程管理的另一个高频需求是“这玩意到底是谁拉起来的”。很多线上事故查到最后都是因为搞不清进程的真实归属和启动方式。遇到这种情况我会按下面这个顺序往下查。第一个用 pstree -ap 看进程树。它能直接展示父子关系一眼看出哪个进程是哪个拉起来的也能辅助判断是不是出现了进程的异常衍生。之前遇到过一台机器上莫名其妙多了一堆同名进程pstree 一看全是某个服务的子进程没退干净问题定位快得不是一点半点。接下来是 /proc 文件系统这是Linux排查的神器。查进程的启动命令用 ps -p PID -o cmd 能看到完整命令行但这个可能被人为改过。更可靠的是直接读 /proc/PID/cmdline 文件这个文件里参数是用 \0 分隔的用 xargs -0 处理一下就能还原出原汁原味的启动命令。想知道进程的启动目录去看 /proc/PID/cwd 这个符号链接想知道进程可执行文件的真实路径看 /proc/PID/exe它能穿透符号链接直接指向真实文件。这些都是日常排查里非常重要的Linux系统管理命令技巧。还有一个容易被忽略的端口和进程的对应关系。服务起不来最常见的原因就是端口被占了。以前大家都用 netstat -tlnp现在我一般直接推荐 ss -tlnp。ss 命令读取的是内核socket信息比netstat快得多在大并发连接下优势尤其明显。输出里最后一列能看到进程名和PID如果是别的用户起的进程你可能看不到PID那就要么切root要么用 lsof -i:端口号 来看。lsof 的优势是能列出所有打开这个端口的文件描述符细节但 lsof 在高负载下偶尔会卡因为要遍历所有进程的fd目录。3. 磁盘和文件系统空间、Inode、IO三件事分开查3.1 df和du的区别为什么删了大文件空间还是满的磁盘排查是Linux系统管理命令里最容易出现“灵异事件”的场景。最常见的现象是du统计出来文件一共就占了几十GBdf一看磁盘用了90%多或者明明删了一个大文件df显示磁盘还是满的。这些现象背后其实是两个命令工作层次不同造成的。df 查的是文件系统层面它看的是整个分区的块使用情况包括元数据、预留块以及那些已经被删除但还被进程占用的文件。du 查的是目录树层面它逐个统计目录下的文件大小。所以 du 算出来的是一个“逻辑”上的目录占用df 看到的才是“物理”上文件系统块的真实分配情况。du 统计慢的问题就没必要吐槽了哈。当你发现文件系统空间满了别着急删文件先按下面这个顺序排查。第一步df -h 看哪个分区满了。第二步用 du -sh /目录/* 或者 du -h --max-depth1 找大目录这个命令我基本每天都要敲几次写脚本时也常用 du -s 拿总值。第三步是个关键点如果你发现删除了文件但空间没释放用 lsof L1 查看所有被删除但还在被进程占用的文件。这条命令会把所有 link count 为0但还被进程持有fd的文件列出来绝大多数“删了空间没回来”的问题都出在这。确认之后重启对应的服务进程或者直接 kill 掉持有者空间立刻就回来了。3.2 Inode和IO瓶颈df不报警不代表磁盘没问题还有一类问题是空间明明有富余但系统报“No space left on device”这个时候基本就是Inode用完了。Inode可以理解成文件系统给每个文件分配的一个索引节点它记录文件元数据。df -i 查看Inode使用率当已用100%时即使有剩余空间也创建不了新文件。清理方法很简单找小文件特别多的目录比如邮件队列、临时目录、Docker的overlay目录用 find /目录 -xdev -type f | wc -l 统计数量再用 find /目录 -xdev -type f -size 0 -delete 批量删除空文件。生产环境尤其是消息队列、定时任务日志那种一天产生几十万个小文件的场景Inode耗尽比空间耗尽更常见监控的时候一定不要漏掉 df -i。磁盘性能这块iostat 是我首选的工具。安装 sysstat 包之后就能用。iostat -x 1 每秒刷新一次重点看 %util 和 await。但这里有个坑要提醒%util 高不代表磁盘坏了它只表示设备有IO请求在排队的时间占比。像高并发随机读写的时候%util 100%其实是正常的关键要看 await平均IO响应时间和 svctm 对比。当 await 远大于 svctm说明有大量请求在队列里等着磁盘确实忙不过来如果两者差不多说明磁盘本身处理能力没问题可能是请求太密集了。更细一点可以用 iostat -d -x 看每块磁盘的读写吞吐量 rMB/s 和 wMB/s配合 iostat -k 1 缩短时间粒度观察趋势。3.3 大文件搜索和清理策略别把时间浪费在一通乱找上在实际工作中定位大文件我有一套自己的方法。先用 df -h 确认哪个分区满了这步不用多说。然后用 du -h -x --max-depth1 /分区挂载点 2/dev/null | sort -rh | head -20 来快速圈定大目录。这里的 -x 参数很重要它让 du 不跨文件系统避免把其他挂载点也算进来这种细节在实际干活的时候很关键。圈定大目录之后再往下走一层用 find /路径 -xdev -type f -size 500M -exec ls -lh {} ; 来列出具体的大文件。这里也用了 -xdev好处一样不遍历其他挂载点。找到大文件之后先确认这个文件是否还被进程占用用 lsof /路径/文件名 来确认。如果文件被占用且可以直接重启服务那就重启如果不方便重启可以用 : /路径/文件名 这个技巧把文件内容清空而不是删除。这样既释放了空间又不影响继续写文件的进程。我处理临时文件还有个习惯定期用 find /tmp /var/tmp -type f -atime 7 -delete 这类命令清掉超过一周没访问的临时文件。但在生产环境要格外小心最好先加上 -mtime 或 -atime 的条件并且先跑一遍 find 不带 -delete 看看结果确认没有误删风险再执行。4. 内存和Swapfree看的是门道vmstat看的是趋势4.1 free输出逐行解读available才是有意义的数字内存管理是Linux系统管理命令的另一大阵营。free -h 这条命令的输出网上讲烂了但我发现大部分人其实就被 buff/cache 给唬住了。机器可用内存显示只剩几百MB立刻开始慌了觉得内存不够了。真不是这样。Linux内核的页面缓存策略是“空闲内存拿来用别闲着”。你把文件读一遍这些数据就会进入 page cachefree 命令里显示为 buff/cache它们看着占用了内存但只要应用程序真正需要更多内存内核会立刻回收这些缓存分配给程序。所以真正的可用内存看的是 available 这一列不是 free 那一列。available 是内核估算出的在不触发Swap的情况下还能分配多少内存给进程。我平时判断一台机器内存够不够优先看 available而不是被那个很小的 free 吓着。如果 available 一直在缩水同时 free 列无限接近0这时就要结合 Swap 来看。free -h 里 Swap 的 si 和 so 解释一下Swap里的 used 不为0是正常的说明之前有一波内存高峰被换出去了不代表现在有问题。但如果你发现交换分区被大量使用并且系统的可用内存也持续偏低那就要警惕了。一个判断依据是看Swap的占用趋势如果持续增长而不是回落基本可以断定有进程在大量吃内存或者更糟出现了内存泄漏。4.2 vmstat和内存排查实操从趋势里读出问题vmstat 是快速定位系统整体健康状态的利器。用法是 vmstat 1 5每隔1秒采样一次共采5次。重点看 procs 区域的 r 和 b。r 代表正在运行和等待CPU的进程数长期大于CPU核数说明CPU饱和b 代表处于不可中断睡眠的进程数长期很大说明IO阻塞严重。内存这块看 si 和 so它们的含义是 swap in 和 swap out 每秒的数据量持续非0说明系统在频繁换页内存基本告急性能已经大打折扣了。用 vmstat 观察趋势比揪着一个瞬间看更有意义。我最常干的事就是 vmstat 1 连续刷几十秒观察 si/so 是不是间歇性飙升观察 r 列是不是随着负载在涨。结合 free -h 的 available能拼出一个比较完整的内存压力变化图。追到进程级别之后第一梯队还是 top 按 M 排序看哪个进程的 %MEM 和 RES 列高。到了这一步还没法区分是内存分配过多还是泄漏那就得用 pidstat -r -p PID 1 持续监控进程的内存变化。这条命令会周期性输出 minflt/s 和 majflt/s也就是进程的缺页中断次数。持续观察 RSS 只涨不降的话内存泄漏基本就坐实了。更专业的可以用 valgrind 做内存检测但那东西跑起来太慢生产环境一般用不上最多在测试环境复现问题用一下。4.3 cache回收和OOM机制什么时候要出手什么时候别乱动有时候确实需要手动释放缓存。比如刚做完一个大文件的归档操作page cache 被塞满导致其他应用申请不到足够内存。用 echo 1 /proc/sys/vm/drop_caches 可以只释放page cacheecho 3 是释放page cache和dentries、inodes。但这东西我劝你谨慎用。平时生产环境别没事就去释放缓存你释放了缓存应用后面又要重新读磁盘反而更慢。只有当你有充分的理由比如批处理任务刚跑完需要给马上要来的高峰腾内存才值得操作。操作前最好先 sync 一下把脏页写回磁盘然后再清虽然echo本身就会触发sync但手动sync多一道保险。内存严重不足时Linux会启动OOM Killer。这个机制本身很粗糙它按坏分度选进程杀结果往往是杀了最不该杀的那个。所以关键进程的OOM保护务必要做。给关键服务设置 -1000 的oom_score_adj写在systemd服务配置的 OOMScoreAdjust 字段里这样内核算出来的OOM分数就会很低不到万不得已都不会动它。查看当前进程的OOM分数可以读 /proc/PID/oom_score。生产环境死得最多的其实就是数据库被OOM杀了所以这一块我每次讲内存排查都会专门强调。5. 网络排查从连接状态到端口连通性一次理清5.1 ss命令实战连接状态统计和TCP状态详解网络问题在Linux系统管理命令里占比不低。以前排查端口和连接信息大家习惯了 netstat但 netstat 慢而且很多发行版新版本默认不装了。我现在的习惯是无脑用 ss。ss -s 可以看整体的连接统计包括TCP的各种状态数量、端口使用情况。这可以作为网络排查的第一步快速判断当前网络连接量级和状态分布。特别要关注的是 TCP 连接状态里的几个异常项。SYN_SENT 一直很多说明你往外连的对方机器没响应可能是对方挂了或者防火墙拦了。SYN_RECV 异常走高基本都是半连接队列满了往往是SYN Flood攻击或者连接负载太大。TIME_WAIT 多不是问题TCP主动关闭方本来就要等2MSL保证旧报文消失状态多说明短连接多这是正常现象。真正需要担心的是 CLOSE_WAIT 大量堆积这个状态是被动关闭方的问题你发出FIN对方没回FIN代码里没关闭连接基本就是应用层连接泄漏了。用 ss -tan state close-wait 可以直接把处于CLOSE_WAIT的连接全部拉出来再对端口的IP做个统计看看是不是集中在哪个连接上。5.2 端口排查和连通性测试链路问题要按层拆端口起不来的场景前文说过用 ss -tlnplsof -i:端口 也能帮助确认端口被哪个进程占用。但有时候你会遇到这样的情况ss 显示服务在监听端口但外部就是连不上。这个时候不能只盯本机了要从链路一层层排查。先在本机测回环curl 127.0.0.1:端口通说明服务本身没问题不通就是服务没监听或者防火墙拦截。再用 ss -tlnp 确认监听地址是不是 0.0.0.0 或 ::如果写着 127.0.0.1那外部当然连不上改服务配置里的监听地址就行。接下来看防火墙iptables -L -n 或 firewall-cmd --list-all 检查端口有没有被放行。很多人用 systemctl stop firewalld 然后发现连上了排查就结束了。但生产环境这么干不是长久之计正确做法是放行对应端口而不是关闭防火墙。本机防火墙放行了还是连不上就要看云平台或者物理网络设备的安全组和ACL有没有放行。这个环节常常让人抓狂因为服务、防火墙、安全组三层都要检查一遍才排得下去。我的建议是按照“本机监听 → 本机防火墙 → 外部防火墙/安全组 → 目标主机回包路由”的顺序一层层排除不要跳步。5.3 ping、traceroute、curl的配合使用网络延迟和丢包怎么定位说到连通性ping 是最常用的工具。但 ping 通了不代表业务正常ping 不通也不代表服务挂了。很多网络设备对ICMP有限速或者直接丢弃我遇到过不少ICMP被禁但TCP正常的网络环境。所以判断链路通不通我更习惯直接用实际端口的 TCP 连接测试。nc -zv 目标IP 端口 可以做一次 TCP 端口测试或者用 curl -v telnet://目标IP:端口 也行实在没有趁手工具用 /dev/tcp 也可以timeout 3 bash -c echo /dev/tcp/目标IP/端口 这种方式虽然粗糙但很多精简环境里很管用。网络延迟和丢包定位traceroute 配合 ping -f 能看出大概的瓶颈段。但这个工具在运营商骨干网里经常被限制走到后半段全是星号是常态。别慌星号只代表那一跳不回应UDP探测不代表断连只要最后的终点能通就没事。如果用 traceroute -T -p 端口 来指定用TCP SYN探测命中率会高不少。丢包和延迟的问题推荐继续用 mtr 来定位。mtr 相当于 traceroute 和 ping 的结合体持续探测每一跳的丢包率。看 mtr 输出的经验是只要最后一跳丢包率是0%中间跳丢包哪怕高也不用太紧张因为很多路由器对探测报文有单独的QoS策略丢的是探测包不丢数据包。如果最后一跳的丢包率跟着上去了那才是真的链路有问题。这套判断逻辑我用过太多次了第一次带新人的时候他们看着全程30%丢包慌得不行我让他们看最后一跳一眼就明白怎么回事了。6. 日志和综合实战把命令串起来解决一个完整问题6.1 journalctl和日志分析系统日志是排障的第一现场应急响应的时候别光顾着看资源占用日志才是判断问题根因的第一现场。现在主流的系统发行版都用 systemd日志体系也统一到了 journald。journalctl 这个命令的重要性怎么强调都不为过。日常排查我常用的几个参数journalctl -u 服务名 查看单个服务的日志-f 实时跟踪--since 1 hour ago 按时间过滤-p err 只看错误级别以上的日志。这几个组合用能覆盖大多数场景。systemd 日志有个特点它默认把日志写到内存里也就是 /run/log/journal重启之后之前的日志就丢了。所以重要机器的持久化日志配置要提前做。在 /etc/systemd/journald.conf 里把 Storage 改成 persistent日志就会写到 /var/log/journal。日志疯长的问题也要防同文件里 RateLimitIntervalSec 和 RateLimitBurst 是限流参数SystemMaxUse 控制日志最大占用磁盘空间。超过阈值会触发日志轮转但轮转本身也是IO操作会被系统限流如果日志量实在太大系统会直接丢日志以保护主流程这个机制叫journald的背压保护。知道这个机制之后你就不会奇怪为什么某些关键时刻日志反而断了那是系统在做自我保护不是bug。传统的 /var/log/messages 或 /var/log/syslog 仍然有参考价值。不管用哪种排查日志的基本功是 grep 过滤和上下文查看先 grep 关键字 找到时间点再用 grep -A 10 -B 5 看匹配行前后的上下文。排查程序崩溃、串扰、权限问题这些场景日志都提供了直接证据。很多线上事故最后复盘都把“日志没看全”列为第一教训真不夸张。6.2 一个完整案例degraded状态下的系统救援实战把前面这些Linux系统管理命令串起来用机会来的时候别慌。我之前处理过一台状况很糟的机器表现是系统异常缓慢服务频繁超时连SSH都偶尔卡顿。当时我用的排查顺序正好能串起这篇文章讲的大半内容。第一步看负载。uptime 显示 load average 在30以上但CPU核心只有8个负载和核心数严重不成比例。第二步用 top 和 vmstat 定位发现 us 占比不高context switch 也没异常倒是 vmstat 的 wa 列长期在50%以上b 列还有不少进程在睡眠状态。到这里基本能判断是IO瓶颈了。第三步用 iostat -x 1 看磁盘发现某块数据盘的 %util 接近100%await 到了几百毫秒svctm 只有十几毫秒。这个对比说明设备本身响应不行大量的请求在排队。接下来就涉及到一个问题这台机器的存储层用的是RAID阵列系统提示阵列状态degraded也就是降级运行。我马上用 cat /proc/mdstat 检查发现确实有一块盘被踢出了阵列。这种状态下整个磁盘阵列以冗余模式全量重建数据IO当然被拖垮。确认了根因之后再处理先找维护窗口把备用盘做替换触发阵列重建重建期间把系统负载降到最低把非核心服务全部停掉保证重建IO能跑满优先恢复冗余。整个过程我按着“看负载→分方向→查IO→确认根因→定向处置”这个逻辑推进没有花太多无效操作。如果是新同学遇到同样的情况很容易在CPU占用率和内存占用上打转磁盘层面反而被忽略了那问题就不好定位了。6.3 快速检查脚本思路把日常体检固化下来排查手法和命令掌握得再熟练每次出问题都在现场手敲一遍也效率太低。我自己维护了一套快速体检脚本的思路分享给你们参考。核心就是在一百多秒内把系统四大块的状态打印出来作为第一手证据留存之后再展开排查也更有底。脚本内容其实不复杂先用 uptime 确认Loadfree -h 和 df -h 看内存和空间vmstat 1 3 看CPU、IO、中断趋势ss -s 看连接状态分布。再加一个最近几条系统错误日志的查询journalctl -p err --since 10 minutes ago -n 20。这些命令组合起来就是个标准体检包。脚本跑完输出的结果直接沉淀成现场记录之后复盘也有据可依。这个脚本不需要很复杂关键是形成肌肉记忆。针对每种异常类型可以再准备一份更细的命令手册比如性能问题看 pidstat、mpstatIO问题看 iostat、iotop网络问题看 ss、sar -n DEV文件系统问题看 df -i、find 大文件。把这些组合梳理清楚配合日常脚本处理问题的速度能上一个台阶。7. 实操心得和踩坑记录7.1 高负载现场最忌讳的操作别急着重启最后聊一些很难从文档里学到的实战心得。第一件事高负载现场别急着重启。我见过太多次了——机器卡了反应不过来第一反应就是重启。但重启意味着去现场的所有现场数据都没有了内存里的状态没了、进程的痕迹没了、日志可能也没及时落盘。除非机器已经完全失去响应且业务影响在扩大否则第一时间应该是做现场快照把能采集的信息都采集下来比如 top -b -n 1 的输出存到文件、ss -s 快照、/proc/meminfo 的备份这些都是事后分析的宝贵证据。第二件事IO延迟高的机器上少跑 du 这类遍历命令。这是个绕不开的自我矛盾机器IO已经堵死了你还跑个 du 去全盘遍历等于火上浇油。最好的做法是用之前提到的 find 配合 -xdev 限制范围或者直接用 df 先看个大概实在需要精确定位再小范围扫。7.2 无效命令组合和时间浪费把操作顺序理顺第三个心得是操作顺序。举例说明你拿到一个系统缓慢的问题正确顺序是先看 uptime 的负载和对应的核心数判断负载是否异常再看 vmstat 的 r、b、wa 几列快速确认CPU还是IO然后才用 top 和 ps 去定位具体进程。很多人一上来就 ps aux --sort-%cpu看到个高CPU进程就当根因结果白白绕了一圈甚至误判方向。操作顺序理顺排障效率会肉眼可见地提升。还有一个平时不注意的坑top 显示的不是真实瞬时占用。这个问题前文提过但值得再强调一次。排查CPU飙升时一定要用 top -H -p PID 看线程级别或用 pidstat -p PID 1 精确到实时采样。否则你把之前的耗时进程指认为元凶清半天发现没效果时间全浪费了。7.3 命令超时和权限陷阱非交互环境下的保命技巧非交互环境下的运行策略也是必修课。写定时任务、告警脚本的时候所有命令都要考虑超时问题。比如 du、find、tar 在大型目录上可能跑很久我们在脚本里统一用 timeout 300 命令 这样的形式包一层超过5分钟就强制结束避免脚本挂死导致连锁反应。还有一个容易踩的坑cron 环境下 PATH 环境变量不一样有的在交互Shell里能用的命令到cron里就“command not found”。解决方法是脚本开头 export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin或者直接用命令的绝对路径。这些细节平时不起眼真出事了才知道有多重要。权限陷阱也要单独提一嘴。很多系统信息在root下才能看到全貌比如其他用户进程的环境变量 /proc/PID/environ非root只能看到一部分。但sudo 也不能无脑用sudo cat /proc/sys/vm/drop_caches 直接执行会报错因为重定向是shell做的shell没有root权限。正确写法是 echo 3 | sudo tee /proc/sys/vm/drop_caches。这类小坑遇到了就知道但在现场临时查很耽误工夫提前记住能省很多事。