在 Linux 服务器运维和开发调试过程中，实时掌握系统资源状态是排查故障、优化性能的基础。当网站响应变慢、服务突然宕机或者程序运行异常时，第一时间查看 CPU 负载、内存占用以及网络端口连接情况，往往能迅速定位问题根源。很多新手习惯于图形化界面的任务管理器，但在纯命令行的服务器环境中，熟练运用 top、free、netstat、ss 等核心工具才是硬实力。本文将深入解析这些命令的用法，结合真实场景模拟，教你如何通过命令行精准“把脉”系统健康状态，避免盲目重启或无效操作。
CPU 与内存监控：透视系统核心负载
CPU 和内存是服务器最宝贵的计算资源，任何异常的高负载都可能导致服务不可用。Linux 提供了一系列强大的原生命令，能够以不同粒度展示资源使用情况。
动态实时监控：top 与 htop
top 命令是 Linux 下最经典的实时性能监控工具。执行 top 后，界面会动态刷新，展示当前系统的整体负载（Load Average）、运行中的进程数、CPU 使用率分布（用户态、内核态、空闲等）以及内存和交换分区的使用情况。
在 top 界面中，重点关注以下几项：
- load average：分别表示 1 分钟、5 分钟、15 分钟的平均负载。如果数值超过 CPU 核心数，说明系统处于过载状态。
- %Cpu(s)：
us代表用户空间占用，sy代表内核空间占用。若sy过高，可能意味着系统调用频繁或驱动有问题；若wa(iowait) 过高，则说明磁盘 IO 是瓶颈。 - 进程列表：默认按 CPU 使用率排序，按下
M键可切换为按内存排序，P键切回 CPU 排序，N键按进程 ID 排序。
虽然 top 功能强大，但界面稍显简陋。htop 是其增强版，提供了更直观的彩色条形图、鼠标交互支持以及树状进程视图。如果系统未预装，可通过 yum install htop 或 apt install htop 安装。htop 允许直接按键杀死进程（F9）或调整优先级（F7/F8），操作体验远优于 top。
内存详情分析：free 与 vmstat
查看内存静态快照最常用的命令是 free。执行 free -h（-h 表示人类可读格式，自动转换为 GB/MB）可以看到总内存、已用内存、空闲内存以及缓冲/缓存（buff/cache）的大小。
这里有一个常见的误区：很多新手看到 available 很小就以为内存不足。实际上，Linux 会将空闲内存用于磁盘缓存以提升 IO 性能，这部分内存在应用程序需要时会自动释放。因此，判断内存是否紧张应主要看 available 列，而非 free 列。如果 available 极低且 swap（交换分区）使用量很高，说明物理内存确实耗尽，系统开始频繁进行磁盘交换，性能会急剧下降。
对于更深层的内存波动分析，vmstat 是个好帮手。执行 vmstat 1 5 表示每秒采样一次，共采样 5 次。输出中的 si (swap in) 和 so (swap out) 列如果持续有数值，表明系统正在频繁使用交换分区，这是内存不足的强烈信号。bi (block in) 和 bo (block out) 则反映了磁盘 IO 的读写频率，辅助判断是否存在 IO 瓶颈。
网络端口与连接状态：诊断通信瓶颈
网络问题往往比计算资源问题更难排查，因为涉及本地端口监听、防火墙规则、路由路径以及对端状态。准确掌握端口占用情况和网络连接状态，是解决“端口冲突”、“连接超时”等问题的关键。
端口监听查询：ss 与 netstat
过去大家习惯用 netstat 查看端口，但该命令属于较老的 net-tools 包，效率较低且已逐渐被弃用。现代 Linux 发行版推荐使用 ss (Socket Statistics) 命令，它直接从内核获取信息，速度更快且功能更强大。
查看当前所有正在监听的 TCP 端口，可使用：
ss -tlnp
参数解释：-t 显示 TCP，-l 显示监听状态，-n 不解析域名（显示 IP，加快速度），-p 显示占用端口的进程名和 PID。
例如，输出中看到 0.0.0.0:80 对应 nginx 进程，说明 Web 服务正常监听。如果想看 UDP 端口，将 -t 换成 -u 即可。
若系统尚未安装 iproute2 包导致无法使用 ss，仍可临时使用 netstat -tlnp，其输出格式类似，但在高并发连接下性能较差。
连接状态深度分析
除了查看监听端口，了解当前的网络连接状态同样重要。服务器出现大量 TIME_WAIT 或 CLOSE_WAIT 连接，往往是程序代码未正确关闭连接或遭受攻击的迹象。
使用 ss -tan | awk '{print $1}' | sort | uniq -c 可以统计各种 TCP 状态的数量。
- ESTAB (Established)：正常建立的连接。
- TIME_WAIT：主动关闭连接的一方会进入此状态，等待 2MSL 时间。若数量巨大，可能耗尽其端口资源，需调整内核参数
net.ipv4.tcp_tw_reuse。 - CLOSE_WAIT：被动关闭连接的一方，等待应用程序调用
close()。若此状态堆积，通常说明代码存在 Bug，未正确关闭数据库或网络句柄。
结合 lsof 命令也能查看端口占用：lsof -i :80 会列出所有占用 80 端口的进程详情，包括用户、文件描述符等信息，适合在不确定进程名时使用。
综合排查实战：从现象到根因的推导
在实际运维中，资源问题往往是连锁反应。例如，数据库查询慢导致应用线程阻塞，进而引发内存飙升和端口连接堆积。因此，需要组合使用上述命令进行综合研判。
场景模拟：网站访问缓慢
- 第一步：看负载。运行
top，发现 load average 高达 20（假设是 4 核机器），且wa(iowait) 占比 80%。这提示瓶颈不在 CPU 计算，而在磁盘 IO。 - 第二步：查进程。在
top中按P排序，发现某个日志写入进程或数据库进程占用极高。或者使用iotop（需安装）直接查看哪个进程在进行大量磁盘读写。 - 第三步：验内存。运行
free -h，发现available内存充足，但si/so在vmstat中有波动，确认不是内存泄漏导致的交换风暴。 - 第四步：检网络。若负载不高但网站仍慢，运行
ss -tan | grep ESTAB | wc -l查看并发连接数。若连接数爆满，可能是遭受 CC 攻击；若大量CLOSE_WAIT，则检查后端代码数据库连接池配置。
通过这种层层递进的排查逻辑，可以快速锁定是磁盘故障、代码死循环、内存泄漏还是网络攻击，从而采取针对性措施，如优化 SQL、扩容磁盘、重启服务或接入高防。
熟练掌握这些命令不仅是运维人员的基本功，也是开发人员编写高性能代码的必备技能。只有透过数据看清系统本质，才能在复杂的生产环境中游刃有余。
