—— 一份骨灰级运维的"私藏"命令合集

凌晨三点，运维工程师小李的手机突然疯狂震动。监控系统显示，公司电商平台响应时间突破10秒，用户投诉开始刷屏。他顶着黑眼圈登录服务器，屏幕上密密麻麻的日志看得人头皮发麻——要是早掌握这几个命令，也不至于在无数次故障排查中走弯路。

一、lsof：端口占用的"侦探"

"网站502了！"开发同事在群里急促喊话。小李第一反应是检查80端口，输入lsof -i :80，终端立刻列出占用进程：

原来上周部署的测试环境nginx没关闭，两个进程争抢端口。他果断执行kill -9 1234，30秒后网站恢复正常。这个命令就像系统侦探，-i参数指定网络接口，:80锁定端口，连隐藏的僵尸进程都无所遁形。

刚解决端口问题，新警报响起：服务器并发连接数突破5万。小李记得老运维说过netstat太慢，改用ss -antp：

结果显示6000多个TIME_WAIT状态连接（连接僵死后未释放）。他立即修改内核参数net.ipv4.tcp_tw_recycle=1，连接数瞬间降至正常水平。比起netstat解析/proc文件系统的老办法，ss通过netlink接口直连内核，在高并发场景下速度提升10倍以上。

业务平稳运行不到两小时，CPU使用率突然飙升到95%。小李敲下dstat --top-cpu，实时监控界面立刻揪出元凶：

一个Java进程占用87%CPU。他远程调用开发排查，发现定时任务逻辑错误导致死循环。这个命令集成了vmstat、iostat的所有功能，--top-cpu插件就像放大镜，直接显示资源消耗冠军，比top命令更直观。

优化后系统仍有间歇性卡顿。小李祭出终极武器perf record -g -p 2345（2345是应用进程ID），采样10秒后生成火焰图：

图中"橙色方块"显示order_process函数耗时最长，开发团队据此重构了订单处理模块，系统响应时间从300ms降至45ms。这个工具能深入内核级分析，连函数调用栈都一目了然。

当太阳升起时，服务器终于恢复平静。小李把这四个命令整理成备忘录——lsof查端口、ss看连接、dstat观全局、perf挖瓶颈，这套组合拳让他在后续半年的故障处理中再没熬过通宵。