企业官网建设流程全解析

干开发、跑训练、做运维的，聊到最后都会碰到同一个坎——Linux 命令用得顺不顺，直接决定你是在解决问题，还是在问题里打转。我带过的不少新人，一开始都在背命令，ls、cd、grep 背得滚瓜烂熟，可真到线上出故障，CPU 飙到 100%，进程卡死，训练任务跑一半没反应，全都懵在原地。

这篇东西不是把命令手册抄一遍，而是按真实排查场景来组织。我会把开发、训练、运维三个角色最常用的命令按场景过一遍，然后把“进程故障排查”单独讲透：从现象、工具、证据、解法四个层面展开，最后用几个我实际踩过的案例做复盘。适合刚开始接触 Linux 的开发者，也适合已经会用一些命令、但遇到故障就手忙脚乱的同学。

1. 先把底层逻辑理清：命令不是用来背的，是用来回答问题的

很多人学命令的姿势不对，拿着命令列表从头背到尾，背完还是不会用。原因在于：命令本身不是目的，它是你回答问题的工具。排查故障的本质，就是在不断向系统提问，然后根据答案决定下一步问什么。这套提问逻辑，比命令本身重要得多。

1.1 开发、训练、运维，三个角色的排查逻辑是同一个

三个角色平时用的命令侧重不一样，但底层逻辑完全一样。开发的日常是：写完代码跑起来，看日志、改 bug，所以文件操作、文本处理、进程重启用得最多；做训练的同学更多跟 GPU、显存、训练进程、数据加载打交道，资源监控和进程管理是命根子；运维同学的核心是服务稳定性，端口、磁盘、负载、网络，一样都不能漏。

但你会发现，大家遇到故障时的动作是一样的：先看全局，再缩小范围，最后定位到具体进程、具体文件、具体一行日志。命令只是这个过程中的“问话方式”。所以我建议你忘掉“按命令分类”的学习方式，改成“按问题场景”来组织你的知识，效果会好得多。

1.2 排查四步法：把故障处理变成流水线

我自己处理故障基本固定走四步，你可以直接抄这个流程：

• 第一步，看现状。用uptime、free -h、df -h、top给系统做个全身检查，确认问题到底出在 CPU、内存、磁盘还是网络。
• 第二步，锁嫌疑。通过ps、lsof、strace把问题范围从“整个系统”缩小到“某个进程”“某个线程”“某个文件”。
• 第三步，收证据。日志、内核消息、进程状态、系统调用，能拿的都拿下来，搞清楚“为什么会变成这样”。
• 第四步，处理与复盘。kill、重启、调参、改代码，把问题解决掉，然后想想怎么防止下次再踩。

这套流程看起来简单，但实际做的时候，很多人会跳步。最常见的就是不看现状直接 kill 进程，结果杀错了，或者问题根本没解决。记住一个原则：任何故障处理，先花 20% 的时间把现状看清楚，后面 80% 的时间才不会被带偏。

2. 高频命令实战清单：按场景分类，随查随用

这一章是干活用的，我把开发、训练、运维三个场景里最常用、最扛打的命令按四类场景列出来。每个命令我会告诉你它解决什么问题、怎么看输出、有什么坑。

2.1 文件和磁盘：先摸清家底

服务器上最容易出问题的就是磁盘，日志没轮转、模型文件太大、临时文件攒了一堆，磁盘一满，服务立刻开始作妖。所以先把文件和磁盘的命令练熟。

查看文件和目录的基本情况，我用得最多的不是ls，而是ls -lht。-l显示详细信息，-h把大小转成人类可读的 K/M/G，-t按时间排序。这样一眼就能看到最近被改动的文件，排查“谁刚写了一大堆东西”特别管用。

磁盘空间用df -h，这个命令看的是文件系统级别的占用。输出里的Use%列超过 85% 就要警惕了，超过 95% 基本是要出事的节奏。但df只能告诉你“哪个挂载点满了”，具体是哪个目录占的，得用du -sh *一层层进去查。我习惯先cd /，然后du -sh */列出根目录下每个一级目录的大小，再顺着大的目录往下钻，很快就能定位到罪魁祸首。

还有个命令容易被忽略：find。排查大文件的时候，我常用find /data -type f -size +1G -exec ls -lh {} \;直接把超过 1G 的文件全列出来，比一层层du快得多。需要清理旧日志时，find /var/log -name "*.log" -mtime +7 -exec rm -f {} \;也可以直接派上用场，但执行rm之前务必先加上-exec ls确认一下要删的东西对不对，我见过太多人一条命令把重要日志全清掉的惨案。

2.2 系统资源与负载：一眼看穿

排查故障第一件事永远是看负载。uptime输出最后三个数字就是 1 分钟、5 分钟、15 分钟的平均负载，注意这个数字是“多少个任务在等待运行”，不是 CPU 使用率的百分比。四核机器负载到 4 说明 CPU 刚好打满，到 8 说明有一倍的任务在排队，这时候系统已经开始卡了。

内存用free -h，重点看两列：available和buff/cache。很多新手盯着used看，发现用了 90% 就慌，其实那里面有很大一部分是文件缓存，可以随时释放给应用程序用。真正要关注的是available，它才是“还能给新程序分配多少内存”的真实答案。另外，swap 的使用量也值得留意，如果 swap 一直在涨，说明物理内存已经不够用了，系统正在用磁盘假装内存，这时候性能会断崖式下降。

动态监控我首选top，进去之后按P按 CPU 排序、按M按内存排序，按1看每个核的使用情况。top默认显示的是所有进程的总览，看它主要用来快速判断“谁在吃 CPU”，但要注意它默认采样间隔是 3 秒，对于瞬间飙高的进程可能抓不到。更精细的可以用pidstat，比如pidstat -p 12345 1 5每秒钟采样一次，连续采样 5 次，专门观察某个进程的行为。htop是top的增强版，界面友好，可以直接鼠标操作，服务器上没装的话apt install htop或yum install htop装一个，日常排查体验好很多。

2.3 网络与端口：服务通不通、谁在占用

网络排查的场景很典型：服务起不来，提示端口被占；服务起来了，但外面访问不到；连接数被打满，请求全部超时。这几个问题各有对应的命令。

查端口占用，首选ss -tlnp，比老的netstat快很多，输出也更清晰。-t只看 TCP，-l只看监听中的端口，-n显示数字格式的 IP 和端口，-p显示占用端口的进程。比如ss -tlnp | grep 8080，直接能看到 8080 被哪个进程占着，拿 PID 再配合ps就能知道是谁在捣乱。如果你需要看某个进程都监听了哪些端口，用lsof -p PID或者lsof -i也很方便。

服务通不通，我自己习惯先ping测网络连通性，再telnet ip port测端口通不通，或者用curl -v http://ip:port看 HTTP 层响应。这里有个经验：ping通了只能说明网络层通，不代表服务本身正常，telnet能通才说明有程序在监听这个端口。排查本机服务问题，还可以用ss -s看当前系统的网络连接统计，如果大量连接处于TIME_WAIT或SYN_SENT状态，通常是连接数或防火墙层面的问题。

2.4 日志与文本处理：在千万行日志里捞针

日志是故障排查的第一现场，但日志文件动辄几百 MB，甚至几个 G，直接打开是不可能的事。这时候文本处理命令就是你的救兵。

grep就不用多说了，我单独提醒一个场景：排查分布式系统或训练任务时，日志是多个进程同时写的，顺序混乱很正常。这时候grep -n显示行号，再配合grep -A 5 -B 5显示匹配行的上下文，才能还原出“错误发生前发生了什么”。日志实时跟踪用tail -f，但生产环境日志刷得飞快的时候，建议先grep过滤再tail -f，比如tail -f app.log | grep --line-buffered "ERROR"，不把废话全打印出来刷屏。

sar命令也是系统排查的好帮手，很多机器自带安装，用来回溯历史负载情况。如果故障已经过去，你想知道“昨晚 3 点到底发生了什么”，sar -q看历史负载，sar -r看历史内存，sar -d看历史磁盘 IO，比你事后瞎猜清晰太多。很多线上问题难以当场抓到现场，sar 的历史数据就是回放现场的关键。文本处理的进阶组合，后面我单独用一个案例来讲awk和sort的配合，这里先不展开。

3. 进程排查方法论：从现象到根因的四步走

命令清单只是弹药库，真正决定你能不能解决问题的，是排查进程故障的思考框架。进程出问题，表象千奇百怪：CPU 飙高、内存暴涨、进程卡死、服务假死、端口被占……但追根溯源，都是“进程在某个资源维度上出了异常”。下面这套四步法，是我处理进程类故障最常用的套路，每一步都有对应的核心命令和判断逻辑。

3.1 第一步：看清进程现状，别急着动手

很多急性子同学看到进程“死了”“卡了”，第一反应就是kill -9，这是一个非常危险的坏习惯。你杀掉一个进程很容易，但如果没有搞清楚它为什么死，重启一百次还是会在同一个地方死掉。

正确做法是先用ps aux看进程全貌。输出里最关键的两列是STAT和%CPU、%MEM。STAT是进程状态，R表示正在运行，S表示睡眠，D表示不可中断的等待（通常是等待磁盘 IO），Z表示僵尸进程，T表示已停止。看到D状态要警惕，说明进程卡在 IO 上，大概率是磁盘出了问题；看到一堆Z状态，说明有父进程没有正确处理子进程退出，属于代码层面的问题。

想查看某个特定进程的详细状态，可以读/proc/PID/status，里面包含了进程的内存、状态、父进程 ID、上下文切换次数等非常详细的信息。比如cat /proc/12345/status | grep -E "State|VmRSS|Threads"，能一次看到进程状态、当前物理内存占用和线程数。这个文件在排查疑难杂症时极其好使，但很多人不知道。

系统层面先用top或htop看整体负载，再用pidstat观察具体进程，能确认问题的所在维度：CPU 型问题、内存型问题还是 IO 型问题。判断维度是后面所有排查工作的基础，维度判断错了，后面全白搭。

3.2 第二步：锁定罪魁祸首，把范围缩到进程和线程

确认了是 CPU 问题之后，下一步就是找到“哪个进程在吃 CPU，它在干什么”。用top -p PID可以只看目标进程，如果想看这个进程内部的每个线程的 CPU 占用，用top -Hp PID。这一步非常关键，因为很多高 CPU 问题不是进程整体的问题，而是进程内部某个线程死循环了。

举个实际例子：某次排查一个 Java 服务的 CPU 飙高问题，top里看到 Java 进程占了 300% CPU，但 Java 进程里有几十个线程，到底哪个线程有问题，光看进程级别是看不出来的。用top -Hp PID找到那个 CPU 占用接近 200% 的线程号，然后把线程号转成十六进制，再到线程 dump 里去找对应的线程栈，才能定位到是某段代码里的死循环。这个过程里，线程号转十六进制是很多人会卡住的点，其实直接用printf "%x\n" PID就能转换。

进程扣留的文件描述符和网络连接，用lsof -p PID查看，可以看到这个进程打开的所有文件、socket、管道。如果怀疑进程是因为文件描述符耗尽而出问题，ls /proc/PID/fd | wc -l直接数一下当前打开了多少个 fd，ulimit -n查看系统的 fd 上限，两者一对比就知道是不是触顶了。这个场景在长驻服务、高并发服务和训练任务里都很常见。

3.3 第三步：深挖现场证据，搞清楚“为什么”

找到嫌疑进程后，下一步是搞清楚它“正在干什么”。这时候最强大的工具是strace，它跟踪进程的系统调用，把进程每次向内核发出的请求全部打出来。strace -p PID实时跟踪，strace -p PID -e trace=file只跟踪文件相关的系统调用，strace -c -p PID可以统计每个系统调用的次数和耗时。

用strace的时候要注意：直接strace -p PID会中断正在运行的进程，因为每次系统调用都要经过 ptrace，性能会骤降。所以在生产环境上，我通常先用-c做一次采样统计，找出高耗时或高次数的系统调用，再决定要不要详细跟踪某个调用。如果进程频繁卡在read上，说明它在等数据；如果频繁write但返回错误，说明磁盘或管道出了问题；如果是训练任务卡住，strace常常能看到进程卡在某个futex或read上，指向锁等待或 IO 阻塞。

内核级别的现场，用dmesg查看。内存不足时内核会触发 OOM Killer，把占用内存最高的进程杀掉，这时候dmesg里会留下“Out of memory: Kill process”的日志，并且会写清楚杀的是哪个进程、系统当时内存耗尽的情况。你发现进程“神秘消失”，第一件事永远是dmesg | tail -50，而不是急着重启，因为如果是 OOM 杀掉的，重启后大概率还会接着被杀。

3.4 第四步：对症下药与复盘，别让问题过夜

定位到根因之后，处理手段要分轻重缓急。kill -15（默认信号）先给进程一个“体面退出”的机会，让它有机会清理资源、保存状态。只有进程完全无响应、kill -15无效的时候，才考虑kill -9强制杀掉。很多训练任务在保存 checkpoint 的时候被杀，模型权重文件坏了，几天的工作全白费，都归功于不分青红皂白地kill -9。

如果是服务型进程，处理完问题后用systemctl restart xxx或对应的启动脚本重启。重启之前，一定要先看一下启动命令是什么。很多人用ps aux | grep查到进程后，不知道它当初是怎么启动的，重启的时候两眼一抹黑。cat /proc/PID/cmdline可以查到这个进程的完整启动命令，把里面的\0替换成空格就能看到原始的样子，这是排查“重启后起不来”问题的关键信息。

处理完别忘了复盘。故障处理的核心价值，一半在现场恢复，另一半在事后预防。恢复后用sar回溯故障时段的历史数据，用日志的grep统计确认错误发生的频率，想想监控上需要加哪些告警。我自己的习惯是每个故障都写一个简洁的复盘文档，包括现象、定位过程、根因、处理动作、后续改进，这个文档比任何命令手册都有价值，因为它是你自己真实踩坑的沉淀。

4. 实战案例拆解：四个真实故障，从现象到根因完整走一遍

方法论说再多，不如真实案例来得直接。下面这四个案例都是我在实际工作中遇到的，出于信息安全考虑，做了一些脱敏处理，但排查过程完全真实。每一个案例我都会按照“现象 -> 初判 -> 定位 -> 根因 -> 处理 -> 复盘”的顺序来讲。

4.1 CPU 飙高：是谁偷走了算力

现象是监控报警：某台应用服务器 CPU 使用率持续 100%，接口响应时间从 50ms 涨到 5 秒，用户开始投诉。

我登上去先uptime，看到 load average 是 8.5、9.2、9.8，一路在涨，确认问题正在恶化。然后top一看，一个 Java 进程占了 350% CPU，其他进程都很正常。这时问题已经锁定到这个 Java 进程了。

接着top -Hp <PID>，发现进程里面有 3 个线程的 CPU 占用特别突出，其中一个线程占了 150%。把这几个线程号转成十六进制，查线程 dump，看到线程栈里反复出现同一个方法的调用。再看代码，发现是一个缓存淘汰的逻辑里写了while(true)，在某种极端情况下永远跳不出去，形成了死循环。

处理方式：先kill -15让线程 dump 输出保存现场，然后重启服务，同时对代码做了修复。复盘时增加了线程 CPU 的监控和线程 dump 的自动抓取机制，以后再出现类似问题能在 1 分钟内拿到现场，不用再临时抓。

这个案例的启示是：CPU 飙高问题，90% 以上都是某个进程内部某个线程死循环，单纯看进程级别没用，一定得下钻到线程级别才看得到真相。

4.2 内存泄漏：进程悄悄变成内存黑洞

现象是服务运行时间越长越慢，定期重启后恢复正常，但过几天又慢了。这个节奏非常典型，基本可以断定是内存泄漏。

我先free -h看内存，发现 available 已经从 32G 掉到了不到 2G，swap 快打满了，系统整体负载已经很高。top按内存排序，看到某个 Java 进程 RSS 占了 28G，而且这个数字还在缓慢上升。

为了验证是否真的在增长，我用pidstat -r -p <PID> 10连续采样，每 10 秒记录一次进程的 RSS 变化，半小时后画成趋势，确认 RSS 呈单边上涨，从不回落。这就是典型的内存泄漏特征：只涨不跌。如果是正常的缓存机制，应该会有释放和波动。

接着用jmap -histo去 dump 堆内存对象统计，发现某类对象数量异常大，并且持有它的引用链非常可疑。再看代码，发现有一个全局的 List，每次请求都会往里塞一个对象，但没有清理逻辑，时间一长内存就被挤爆了。

处理：先重启缓解现状，然后修复代码，给这个 List 加了大小上限和过期清理。复盘时给内存加了监控告警，RSS 持续超过阈值就报警。

这里特别想提醒训练场景的同学：训练进程跑几天之后出现 OOM，很多人直接调小 batch size，其实可能是代码里有个 list 或 cache 在每个 step 不断累积。排查思路完全一样，用pidstat -r看 RSS 趋势先确认是不是泄漏，再深挖代码。

4.3 训练任务假死：卡在“D”状态该怎么办

现象是训练任务跑了一整天，突然 loss 不再下降，日志也不再刷，进程还活着，但 GPU 利用率掉到 0%。

登上去ps -aux | grep train，发现训练进程还在，但 STAT 列显示D+，也就是不可中断睡眠状态。这种状态意味着进程卡在某个 IO 操作上，极大概率是磁盘出了问题。

dmesg | tail -50里看到了一系列 IO 错误，确认是存储设备故障。再用iostat -x 1，看到某个磁盘的%util达到 100%，await时间长达几百毫秒，而正常应该是个位数。这就解释通了：训练进程在周期性保存 checkpoint 或读取数据时，触发了对这块故障盘的读写，然后卡在内核的 IO 等待，连kill -15都没反应，因为这种 D 状态进程在内核态，信号根本递不进去。

处理方式：修复存储设备层面问题后，进程恢复运行。当时做了一个临时方案：把数据从故障盘迁移到健康盘，修改数据路径后重启训练。复盘时增加了对存储设备的监控告警，iostat和dmesg都接了监控。

这个案例给训练场景的参考价值很大：训练任务卡死不一定是你代码的问题，很可能是 IO 子系统出了问题。看到 D 状态优先查磁盘和内核日志，不要一上来就重启任务，那样会把出问题时的现场丢掉，而且如果是硬件问题，重启了也还会再卡。

4.4 端口被占与连接数打满：服务被谁堵死了

现象是服务发布后启动失败，日志报“Address already in use”。

先ss -tlnp | grep <port>，看到端口确实被一个旧进程占着，PID 是另一个服务的。这就是典型的端口冲突。处理很简单，要么等旧进程自己退出，要么确认旧进程可以结束后kill掉再启动新服务。

另一个连接数打满的场景更典型：某服务反馈大量用户请求超时，我ss -s一看，系统有几十万个 socket 处于TIME_WAIT状态。TIME_WAIT 是 TCP 连接正常关闭后的状态，会持续 60 秒，高并发服务中大量短连接很容易把连接表打满。看ss -tlnp里的半连接数SYN_RECV也异常高，说明并发量确实很大。

处理方式是两层：应用层连接复用（长连接代替短连接），系统层调整内核参数。比较常用的调参包括缩短TIME_WAIT复用相关的内核参数，但这类调参要谨慎，建议在压测环境先验证，再上生产。这个案例的核心经验是：连接数问题先分清楚是“正常的业务并发”还是“异常连接堆积”，如果业务本身并发就是这么高，应该从架构层面解决，而不是单纯调内核参数硬扛。

5. 高频命令速查表与避坑清单

把前面讲到的命令和排查场景总结成速查表，方便你贴在手边随查随用。同时附上我自己这些年踩过的坑，每条都是用真金白银的教训换来的。

5.1 高频命令速查表

5.2 避坑清单：这些坑我替你踩过了

第一条：不要动不动就kill -9。这句话我在前面反复强调，因为它太重要了。kill -9在内核层面直接杀死进程，不给进程任何清理机会，可能导致文件损坏、状态不一致、训练 checkpoint 写一半。默认信号是kill -15（SIGTERM），它会给进程一个机会做清理和保存。除非进程完全卡死（比如 D 状态），否则永远先-15。

第二条：改内核参数前一定要先备份。很多同学在网上看到“优化内核参数”的文章就照着改，改完系统起不来。所有修改/etc/sysctl.conf的操作，之前先sysctl -a > /tmp/sysctl_backup.conf做备份，改完用sysctl -p生效，并且先在测试环境验证。生产环境改内核参数，我个人的底线是：必须有明确的收益数据和测试结果，否则不动。

第三条：strace 别直接怼在生产进程上。strace -p PID会让目标进程的每次系统调用都经过 ptrace，性能损耗可以达到几倍甚至几十倍。高并发服务被 strace 跟踪时，可能出现“没被故障打死，先被排查工具拖死”的尴尬。先strace -c -p PID短时间采样，拿到统计结果再决定是否深入。

第四条：磁盘满了别急着删文件。有一种常见情况是df -h显示 100%，但你du查下来所有目录加起来远没达到磁盘容量。这是因为有进程已经把文件删掉了，但文件句柄还开着，磁盘空间被“已删除但未释放”的文件占着。排查方法：lsof | grep deleted，找到那个还在占用已删除文件的进程，重启它或让它重新打开文件，空间才会真正释放。

第五条：看内存不要被used骗了。Linux 的内存管理会把空闲内存用作文件缓存，表现是used很高、free很低，但系统其实运行得很健康。只看free判断内存不足，是新手最常见的内存误判。记住：真正能反映内存紧张的是available持续走低和 swap 持续增长。

第六条：僵尸进程杀不掉是正常的。kill -9对僵尸进程无效，因为它已经死了，只是它的“遗骸”还挂在进程表里，等着父进程来收尸。处理僵尸进程要去找它的父进程，ps -o ppid= -p <僵尸PID>查看父进程 PID，然后要么让父进程正常处理子进程退出，要么处理父进程。如果父进程是一号进程且长期不清理，问题通常出在代码没有正确wait()。

第七条：定位耗时问题，先看清楚是 CPU 耗时还是 IO 耗时。很多人遇到接口慢就去看代码，容易漏掉真正的原因。先用pidstat或top看进程 CPU 利用率，再用iostat看磁盘是否繁忙，判断耗时瓶颈是 CPU、磁盘还是网络。我之前排查过一个接口慢的问题，看到的是 CPU 占用很低的，怀疑是锁问题，结果是磁盘 IO 排队，换了一块盘就好了。维度判断错误，后面所有的排查动作都会跑偏。

第八条：训练任务排查，别只盯着 GPU。GPU 利用率掉到 0%，大多数人会去查模型代码、查 loss，实际上数据加载的瓶颈更容易被忽略，比如磁盘 IO 拉胯、数据预处理卡在 CPU 单线程、或者 dataloader 的 num_workers 设置不合理。排查训练性能问题时，我会同时开四个终端：nvidia-smi看 GPU 利用率，free -h看内存，iostat看磁盘，top看 CPU。四个维度同时看，才能找到真正的瓶颈在哪里。

6. 关于工具和习惯的几点建议

命令工具固然重要，但真正让一个人从“会用 Linux”升级到“专业排障”的，是习惯。这里分享几个我保持了很多年的工作习惯，希望对你有用。

习惯一：能看现场，绝不靠猜。遇到故障的第一反应，永远是保存现场，而不是急着恢复。进程快照、线程 dump、日志上下文、dmesg 输出、ss 连接状态，这些现场数据一旦丢失，故障复盘的难度会成倍上升。我甚至建议你在接手一个重要服务的时候，先把它的进程清单、端口清单、启动方式、日志路径整理成一份文档存着，故障时这份文档就是你的第一张地图。

习惯二：把常用排查动作写成脚本。dmesg | tail -50、ss -tlnp、free -h、ps -aux --sort=-%cpu | head -10这些高频操作，整理成一个diag.sh脚本，一键输出所有诊断信息，故障时直接跑一遍，几秒钟就能拿到全局信息，比自己一条条敲快十倍。脚本要轻量、只读、不修改任何配置，这样才敢放心在生产环境跑。

习惯三：定期做“消防演练”。我所在团队每季度会挑一台测试机，人为制造一次故障，比如写满磁盘、杀掉核心进程、模拟内存吃紧，让大家在低压力环境下练一遍排查流程。这种练习的价值不在于学会某条命令，而在于把“先看现状、再锁嫌疑、收集证据、处理复盘”这个流程变成肌肉记忆。真到生产环境出大故障的时候，心态稳不稳，差别非常大。

习惯四：把故障当作代码 bug 一样对待。每次故障处理完，都值得像修复了一个线上 bug 一样，写清楚根因、处理过程和预防措施。这不是形式主义，而是给自己的知识库添砖加瓦。时间长了你会发现，你处理过的故障越多，新故障处理起来就越快，因为绝大多数新问题的表象虽然不同，但底层逻辑和你经历过的某个老问题往往是相通的。

工具会更新，命令会有新增，但这种“系统式排查”的思维方式，十年后依然不过时。