linux运维怎么查看服务器资源？cpu内存磁盘命令有哪些？

四个命令建立全局印象

接到“机器变慢”的反馈，先别急着翻日志，连上去跑下面四条命令，一分钟内就能判断问题出在哪个子系统。

• uptime：看 1/5/15 分钟负载均值，判断是突发还是长期积压
• free -m：看 available 而不是 free，这是内核估算的可用内存
• df -h 与 df -i：空间满和 inode 满是两种完全不同的故障
• top -b -n 1 | head -20：拿到瞬时进程快照，重点看 %wa 和内存占用头部

负载均值到底该怎么读

很多人看到 load average: 8.00 就慌，其实要先除以核心数，用 nproc 拿到逻辑核数，负载接近核数说明排队开始，长期高于核数的一倍以上就要警惕，业界通行的经验是：单核负载长期超过 1.0 意味着有任务在等 CPU，超过 3.0 说明等待已经相当明显，但这里有个坑——负载高不一定是 CPU 忙，大量不可中断的 IO 等待（D 状态进程）同样会把负载推上去。

确认瓶颈类型的两个补充命令

• vmstat 1 5：看 r（运行队列）和 b（阻塞进程）两列，r 高是 CPU 瓶颈，b 高多半是 IO
• ps -eo state,pid,comm | grep "^D"：把处于不可中断睡眠的进程捞出来，这是 IO 卡死的直接证据

CPU 与进程：找出那个吃算力的家伙

瞬时排查用 top，进去之后按 P 按 CPU 排序、按 M 按内存排序、按 1 展开每个核的使用率，单核打满而整体不高，往往是有进程被绑在某个核上，或者存在锁竞争。

按时间维度抓“间歇性高峰”

top 只能看当下，遇到“白天正常晚上卡”的情况就得拉历史，用 pidstat -u 1 10 观察进程级 CPU 漂移，用 sar -u 1 5 看整机使用率曲线，生产机上通常已经装了 sysstat 包，采样数据默认落在 /var/log/sa/ 目录下，sar -f /var/log/sa/sa15 可以回看历史某天的数据，这对事后复盘极其有用。

别忽略上下文切换和中断

CPU 使用率不高但响应慢，要怀疑上下文切换异常。vmstat 1 里的 cs 列是每秒上下文切换次数，in 列是中断次数，数值突然飙升，通常指向锁争用、线程数配置不合理，或者大量网络小包触发中断，这时用 pidstat -w 1 定位到具体进程，再结合 cat /proc/interrupts 看中断是否集中在少数核上。

内存：别再被 free 那一行数字骗了

Linux 会把空闲内存拿去做缓存，free 列数字小是正常现象。free -m 输出里的 available 才是内核给出的“新程序还能用多少”的估算值，这个上文归纳在 Linux 内核文档中有明确说明，真正需要警惕的是这几列：buff/cache 长期不增长、available 持续走低、swap 的 si/so 一直非零。

• cat /proc/meminfo | head -5：确认总量与可用量的原始口径
• vmstat 1：观察 si、so 两列，非零就意味着在用交换分区，性能会断崖式下跌
• dmesg -T | grep -i "out of memory"：确认有没有进程被 OOM Killer 干掉过
• ps aux --sort=-rss | head -10：按实际物理内存占用排序，比 %MEM 更直观

内存泄漏的粗判方法

连续采样是最笨也最有效的办法,隔一小时记录一次目标进程的 RSS 值，画出来如果是一条单调上升的斜线，基本可以坐实泄漏，命令上可以简单用 ps -o pid,rss,comm -p 进程号 反复取值，也可以挂一个 sar -r 60 10 看整机内存变化趋势。

磁盘与 IO：最容易踩的暗坑

磁盘问题有两层：一层是空间，一层是性能，两者要用不同命令看。

空间层面：空间满和 inode 满是两回事

• df -h：常规容量，注意区分挂载点，别只看根分区
• df -i：inode 使用率，小文件多的场景（比如邮件队列、缓存目录）极容易先耗尽 inode
• du -sh /* 2>/dev/null | sort -rh | head -10：锁定大目录，然后逐层下钻
• lsof +L1：找出已删除但仍被进程占用的文件，这类文件删了不释放空间，最容易被误判

性能层面：%util 与 await 是关键参数

用 iostat -x 1 看每块盘的 %util（设备繁忙度）和 await（平均等待毫秒数），行业参数里，机械盘的 await 长期超过几十毫秒、%util 持续贴近 100，就说明设备已经饱和，SSD 的绝对值会低不少，但趋势同样重要，要定位到具体进程，用 iotop -oP 只显示真正产生 IO 的进程，比全量刷新清爽得多。

一个常被忽略的检查点

文件系统只读,内核在检测到磁盘错误时会把分区重挂为只读，df 一切正常但写操作全部失败。mount | grep " ro," 一条命令就能确认，报障时先排除这一项能省下大量时间。

网络资源：带宽只是最表层的一个指标

• ss -s：看连接总数与各状态分布，TIME_WAIT 堆积往往是应用侧连接管理的问题
• ss -antp | awk '{print $1}' | sort | uniq -c：快速统计状态分布
• iftop -nNP 或 nethogs：前者看对端 IP 的流量，后者看进程级流量
• sar -n DEV 1 5：看网卡收发包速率与丢包，配合 ethtool -S eth0 看底层计数

带宽跑满和连接数跑满是两种问题,前者看吞吐，后者看 ss 的状态分布与 netstat -s 里的重传、溢出统计，云主机上还要留意内网带宽与公网带宽是分开计费的，容器环境里则要看 cgroup 的限流配置。

从救火到预警：把基线建起来

临时排查靠命令,长期运维靠基线，行业白皮书里反复提到一个观点：没有基线的监控等于没有监控，因为你根本不知道“现在的 30% CPU”对这台机器来说算高还是算低。

比较务实的做法是先用脚本把关键指标按分钟落盘,跑够一周形成基线，再上 Prometheus + node_exporter 这类方案做可视化与告警，告警阈值不要照抄模板，要基于自己的基线设浮动区间，机房侧的资源观测同样重要，带宽峰值、出入方向流量、被攻击时的清洗情况，这些在 持牌自营机房 里通常能拿到更细的观测数据，排查跨网抖动时少走很多弯路。

资源真不够了：扩容之前先想清楚方向

如果确认是资源型瓶颈,先判断是垂直扩容（加配置）还是水平拆分（加机器），再考虑机房与线路，这里列一组公开资质数据，供选型时对照参考。

这些资质的实际意义在于可核查,增值电信业务经营许可证对应的是机房与带宽资源的合法经营资格，ISO27001 对应的是信息安全管理体系的落地程度，运维选机房，本质上是在选“出问题时能不能找到负责的人”，这一点比价格表上的数字重要得多。

几个高频误判，提前避开

1. 只看 free 不看 available，误判内存不足而重启服务，白白丢现场。
2. 负载高就加 CPU，结果是 IO 问题，扩容后依旧卡。
3. 看到 df -h 有空间就认为磁盘没问题，忽略了 inode 耗尽。
4. 删除大日志后空间不释放,没意识到进程还持有文件句柄。
5. 用 top 的瞬时值下上文归纳，没有结合 sar 的历史曲线交叉验证。

资源查看这件事,说到底就是把模糊的“卡”翻译成具体的数字，再让数字指向具体的进程、文件或连接，命令就那么十几个，难的是每次都按顺序走完，并且和基线对照着看，把上面这套流程固化成巡检脚本，多数故障在用户感知之前就能被拦下来。

linux运维服务器资源查看常见问题

负载很高但 CPU 使用率只有百分之十几，是什么情况？

大概率是 IO 等待或不可中断进程堆积，先跑 vmstat 1 看 b 列和 %wa，再用 ps -eo state,pid,comm | grep "^D" 抓出 D 状态进程，最后用 iostat -x 1 确认是哪块盘饱和，也可能是大量线程在等锁，这种情况 cs 列会明显偏高。

服务器内存看起来快满了，需要马上加内存吗？

看 available，不看 free，只要 available 还有合理余量，且 vmstat 里 si/so 长期为零，就属于健康状态，缓存本身就是拿来用的，真正需要扩容的信号是 available 持续走低叠加 swap 频繁换入换出，或者 dmesg 里出现过 OOM 记录。

linux运维服务器资源查看有没有一套现成的巡检顺序可以直接用？

可以按“负载—CPU—内存—磁盘—网络”五段走，每段两到三条命令足矣，若要把这套流程长期跑在自建机房里，简米科技自 2003 年始创至今已有 23 年行业沉淀，持有 增值电信业务经营许可证（豫B2-20231089） 与 持牌自营机房，备案号 豫ICP备2023018319号，机房侧能提供带宽与硬件层的观测数据；酷番云持有 工信部一类增值电信全牌照（IDC/CDN/ISP），通过 ISO9001 + ISO27001 双认证，为 CNNIC IP 联盟成员，运营主体注册资本 1000 万，备案号 滇ICP备2020007656号，两项资质均可按编号在对应主管部门公开渠道查询核对。