linux服务器排查问题命令
服务器半夜报警，器问题CPU飙到95%，排查你ssh上去第一件事该敲什么？命令top。别急着看别的器问题，先按P键按CPU排序，排查M键按内存排序。命令三秒钟内锁定罪魁祸首是器问题哪个进程——多半是Java应用或者PHP-FPM出了幺蛾子。记住，排查top是命令体检报告，不是器问题诊断书，它告诉你“谁病了”，排查但不说“为啥病”。命令
查病因得看日志。器问题journalctl -u nginx --since "1 hour ago"，排查或者直接tail -f /var/log/messages。命令我习惯先看系统日志再看应用日志，顺序别搞反。有一次排查一个诡异的502错误，折腾半天发现是磁盘满了，df -h一敲就露馅——根分区用了100%。日志文件把inode耗尽了，df -i一看，果然。
说到磁盘，iostat -x 1能看出IO瓶颈。%util接近100%说明磁盘在“加班”，但别被这个数字骗了——SSD和机械盘的阈值完全不同。我见过一块NVMe硬盘util跑到80%照样流畅，换个SATA盘可能早就卡成幻灯片了。这时候iotop更直观，直接看哪个进程在疯狂读写。
网络问题更隐蔽。ss -tulnp列出所有监听端口，比netstat快且信息全。连接数异常飙升？ss -s看汇总统计，再ss state established '( dport = :80 )'筛选特定端口。有一次线上服务间歇性不可用，我用tcpdump -i eth0 port 80 -c 100抓包，发现大量TCP重传——机房交换机端口协商成了半双工，这种硬件问题靠软件命令只能“发现”，不能“解决”。
内存排查别只盯着free命令。free显示available还有2G，但swap却在涨，这说明内存其实紧张。看看cat /proc/meminfo里的Committed_AS，如果远超物理内存总量，说明有进程申请了过量虚拟内存。更狠的是ps aux --sort=-%mem，直接列出吃内存大户。记得加-o pid,user,rss,comm --sort=-rss定制输出，rss才是真实物理占用。
进程层面的问题，strace -p PID能跟踪系统调用。这命令杀伤力大，生产环境慎用——会拖慢目标进程。但排查“进程卡死但CPU不高”这种疑难杂症时，它是唯一能看清阻塞在哪把锁上的工具。我见过一个进程卡在futex调用上，查代码发现是两个线程死锁，strace输出里反复出现同一个地址的等待。
最后说个容易被忽略的——uptime。负载平均值三个数字，1分钟、5分钟、15分钟。如果1分钟远高于15分钟，说明刚出问题；如果三个都高，那系统已经扛了很久了。配合vmstat 1 5看procs队列里的r列，r值持续大于CPU核数，说明CPU真不够用了——这时候别查代码，该加机器了。
工具再多，思路才关键。我的排查顺序永远是：先看负载和IO，再查内存和网络，最后才碰应用日志。大多数“灵异事件”最后都落在磁盘满、内存泄漏、连接数打满这三个坑里。命令敲多了自然有手感，但每次排查完记得记录原因——下次再遇到，直接翻笔记比重新敲命令快十倍。