1. 从“看个大概”到“精准定位”为什么你需要掌握系统资源查询在服务器运维、应用性能调优甚至是日常排查个人电脑卡顿的时候我们最常问的几个问题就是“CPU现在忙不忙”、“内存还够用吗”、“磁盘是不是快满了”、“程序是不是卡在IO上了”。这些问题看似基础却是诊断系统健康状况、定位性能瓶颈的起点。很多人可能只会用top或htop看一眼得到一个笼统的印象但面对复杂的生产环境这种“看个大概”的做法往往不够用。比如你发现一个Java应用响应变慢top显示CPU使用率不高但系统负载Load Average却很高。这时候你就需要更精细的工具来判断是等待磁盘I/O的进程太多还是内存不足导致频繁的Swap交换亦或是某个进程陷入了不可中断睡眠D状态再比如磁盘使用率显示还有30%空间但应用却报“磁盘空间不足”这可能是因为inode用尽了而df -h命令默认不显示这个信息。掌握Linux下查询CPU、磁盘、内存、IO使用率的全套方法就像医生掌握了听诊器、血压计和X光机。它让你能从“感觉系统有点慢”的模糊描述快速定位到“CPU的sy系统态使用率异常升高疑似系统调用频繁”或“某块NVMe SSD的读写延迟await飙升到200ms以上”的具体问题。这不仅是一个运维工程师的基本功也是任何在Linux环境下进行开发、测试工作的开发者应该具备的核心技能。本文将带你超越top和free -m深入一套从全局概览到深度剖析的命令行工具集让你真正看懂系统的“生命体征”。2. CPU使用率不只是那个百分百的数字CPU使用率是我们最关注的指标之一但它背后的含义远比一个简单的百分比复杂。在Linux中CPU时间被划分为几个不同的状态用户态us、系统态sy、空闲id、等待I/Owa、硬件中断hi、软件中断si等。一个健康的系统其CPU时间应该主要消耗在us运行用户程序和id空闲上。其他指标的异常升高往往指向特定问题。2.1 实时监控与进程级洞察top/htop与pidstattop命令是实时监控的瑞士军刀。启动top后第一行显示的load average1分钟、5分钟、15分钟平均负载需要结合CPU核心数来解读。如果1分钟负载远高于CPU核心数说明系统在过去一分钟内非常繁忙。top的CPU行是关键%Cpu(s): 12.5 us, 6.2 sy, 0.0 ni, 81.0 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 stus(user): 12.5% 的CPU时间用于运行用户空间进程。sy(system): 6.2% 用于运行内核空间进程系统调用。wa(iowait):这是非常重要的指标。0.0% 表示几乎没有进程在等待磁盘I/O。如果这个值持续很高比如超过20%通常意味着磁盘是系统瓶颈。st(steal): 在虚拟化环境中如果宿主机繁忙你的虚拟机CPU被“偷走”的时间。非零值可能意味着宿主机资源紧张。对于进程级的CPU消耗top下半部分的列表按%CPU排序一目了然。但top的缺点是刷新时可能错过短时进程。htop是top的增强版界面更友好支持鼠标操作、树状视图和颜色高亮是交互式监控的首选。如果我们需要以固定间隔采样并记录数据用于后续分析pidstat是更好的选择。例如每2秒采样一次共采样5次并显示每个进程的详细情况pidstat -u 2 5输出会包含%usr、%system、%guest运行虚拟机CPU时间、%wait等待CPU时间注意与wa不同和%CPU总使用率。这对于捕捉间歇性的CPU峰值问题非常有效。2.2 整体统计与性能剖析vmstat与mpstatvmstat命令提供的是系统整体的一个快照它不仅能看CPU还能看内存、进程、IO等是一个综合报告工具。vmstat 1 5 # 每1秒采样一次共5次关键列r(run queue): 等待运行的进程数。如果持续大于CPU核心数说明CPU资源不足。us,sy,id,wa,st: 与top中含义相同。mpstat则是专门针对多核CPU的利器。在如今多核处理器普及的时代只看整体CPU使用率会掩盖单个核心过载的问题。mpstat -P ALL 1 3 # 每1秒报告一次所有CPU核心的状态共3次这个命令会列出每个逻辑核心的详细使用率。你可能会发现虽然整体CPU使用率只有50%但其中一个核心的使用率是100%其他核心却很闲。这通常意味着应用程序是单线程的或者没有做好CPU亲和性affinity绑定存在线程在核心间频繁迁移context switch的开销。实操心得遇到CPU使用率高的问题不要只看%CPU。首先用mpstat看是否是单核瓶颈然后用top看wa值排除IO等待最后用pidstat定位到具体进程并结合top的TIME列进程累计占用CPU时间判断是长期占用还是短期爆发。对于Java应用结合jstack查看线程栈能进一步定位到代码行。3. 内存使用率理解“已用”与“可用”的真相Linux的内存管理非常复杂其设计哲学是“不用白不用”。因此我们看到free -m的输出时常常会困惑为什么“已用”内存那么多但系统似乎并不卡顿。3.1 破除“内存恐慌”详解free命令直接运行free -m以MB为单位显示total used free shared buff/cache available Mem: 7823 4521 234 627 3067 2456 Swap: 2047 0 2047total: 总物理内存。used: 已使用的内存。注意这个值包含了buffers和cached所以通常很大。free: 完全未被使用的内存。这个值小不一定代表内存紧张。buff/cache: 这是关键包括缓冲区Buffers存储磁盘元数据和缓存Cache存储文件内容。这部分内存在应用程序需要时可以被立即释放所以它属于“可用内存”范畴。available:这是最应该关注的指标。它估算的是在不进行Swap的情况下可以分配给新应用程序的内存大小。它等于free 可回收的buff/cache。上例中虽然free只有234MB但available高达2456MB说明内存非常充裕。Swap: 交换分区使用情况。如果used持续大于0且还在增长说明物理内存已不足系统开始使用磁盘作为内存扩展这将导致性能严重下降。所以判断内存是否紧张核心是看available是否充足以及Swap是否被频繁使用。一个更直观的命令是free -h人类可读格式。3.2 深入内存细节/proc/meminfo与smem/proc/meminfo文件提供了最详尽的内存信息。free和top等命令的数据都来源于此。直接cat /proc/meminfo可以查看所有细节比如Slab内核对象缓存、SReclaimable可回收的Slab、SwapCached被换出但又被换入仍留在Swap缓存中的内存等。smem命令则提供了更先进的进程内存报告视角。它主要报告USS、PSS、RSSRSS(Resident Set Size): 常驻内存集进程实际占用物理内存的大小。但多个进程共享的库会被重复计算。PSS(Proportional Set Size): 按比例分摊共享库后的内存占用。比如一个10MB的库被10个进程共享每个进程在PSS中算1MB。这是衡量进程内存占用的更准确指标。USS(Unique Set Size): 进程独占的、不共享的内存大小。这是当进程被终止时可以释放的内存。使用smem -k -s uss可以按USS排序快速找出独占内存最多的“内存大户”。3.3 识别内存泄漏与Swap风暴内存泄漏的典型表现是某个进程的RSS或PSS随时间持续增长即使在其活跃期过后也不下降同时系统的available内存持续减少最终可能触发OOM-Killer内存耗尽杀手来终止进程。Swap风暴则发生在物理内存严重不足时。你可以用vmstat 1观察si(swap in) 和so(swap out) 两列。如果它们持续有较高的数值每秒几百KB以上说明系统正在频繁地进行内存页换入换出磁盘IO会成为瓶颈系统响应速度将变得极慢。踩坑记录曾经遇到一个案例free显示available内存充足但应用频繁发生短暂卡顿。后来用sar -B 1发现pgscankkswapd扫描的页数和pgscand直接内存回收扫描的页数指标很高说明内核正在后台积极地进行内存页回收虽然还没用到Swap但这种回收压力已经影响了应用性能。根本原因是某个进程虽然RSS不高但申请了大量短期内存导致页表项和缓存碎片化。解决方法是调整内核参数vm.swappiness或优化应用的内存分配模式。4. 磁盘使用率与IO性能空间与速度的双重考验磁盘问题分为两类空间不足和性能瓶颈IO延迟高。两者都需要监控但使用的工具侧重点不同。4.1 空间监控df、du与inodedf -h是最常用的查看磁盘空间使用率的命令。“-h”参数表示以人类可读的格式G、M显示。df -h / /home /data # 查看指定挂载点重点关注Use%列。通常建议在空间使用率达到80%之前进行清理或扩容因为有些文件系统在快满时性能会急剧下降且日志文件可能无法写入。du -sh *命令用于查看当前目录下每个文件和文件夹的磁盘使用情况。“-s”表示总计“-h”表示人类可读。要找出占用空间最大的目录可以结合sortdu -sh /var/* | sort -rh | head -10一个经典的坑磁盘空间未满却报“No space left on device”。这很可能是因为inode用尽了。每个文件包括目录、设备文件等都会消耗一个inode。使用df -i来查看inode使用情况。df -i /home如果IUse%达到100%即使Use%还很低也无法创建新文件。这种情况常见于存储海量小文件如邮件、日志、缓存的系统。解决方法通常是清理无用文件或者重新规划存储结构。4.2 IO性能监控iostat、iotop与await指标当应用响应慢且CPU的wa值很高时磁盘IO很可能就是罪魁祸首。iostat是诊断IO性能的核心工具。iostat -dx 1 5 # -d显示设备报告-x显示扩展统计每1秒一次共5次关键列解读以sda设备为例r/s,w/s: 每秒读写请求数IOPS。rkB/s,wkB/s: 每秒读写数据量吞吐量。await:平均每次IO请求的等待时间毫秒。这是衡量磁盘响应速度的最重要指标。对于机械硬盘await通常应低于20ms对于SSD应低于5ms。如果await远高于此说明磁盘已经饱和或存在故障。%util: 设备带宽利用率。对于机械硬盘这个值接近100%意味着磁盘持续满负荷运转。但对于SSD或RAID阵列由于它们可以并行处理请求即使%util达到100%await也可能依然很低性能依然良好。因此await比%util更能真实反映用户体验到的IO延迟。iotop类似于top但是用于监控进程级别的磁盘IO活动。它可以实时显示哪个进程在读/写磁盘以及读写速度。这对于定位某个“疯狂写日志”或“全表扫描”的进程非常有用。4.3 进阶工具与场景分析sar与blktracesarSystem Activity Reporter是一个历史数据收集和报告工具非常适合做事后分析。它通常由sysstat包提供并配置了cron任务定期收集数据。sar -b 1 3 # 查看过去1秒内的IO传输速率历史如果已配置 sar -d -p 1 3 # 查看设备级IO活动类似iostat的历史数据如果问题已经发生可以去/var/log/sa/目录下查找历史数据文件如sa21对应21号的数据用sar -f /var/log/sa/sa21 -b来回溯当时的IO情况。对于极其深入的IO路径延迟分析blktrace和blkparse是终极武器。它们可以跟踪一个IO请求从块设备层下发到最终完成所经历的每一个步骤如排队、合并、调度、驱动处理、硬件中断返回等的时间。但这套工具使用复杂输出信息庞大通常只在排查内核或驱动级IO问题时由资深工程师使用。性能调优经验一次线上数据库性能抖动iostat显示await高达200ms但%util只有70%。初步判断不是磁盘带宽瓶颈。用iotop发现有一个备份脚本正在执行rsync产生了大量随机读IO干扰了数据库的顺序写。调整备份时间窗口后问题解决。关键点高await不一定意味着磁盘慢也可能是IO队列太长或遇到了不友好的混合读写模式。需要结合r/s、w/s和iotop的进程信息综合判断。5. 综合监控与可视化打造你的系统仪表盘命令行工具适合即时排查和脚本化监控但长期趋势分析和多指标关联观察则需要借助更强大的综合监控系统。5.1 一站式监控方案nmon与glancesnmon是一个交互式系统监控工具在一个屏幕内同时显示CPU、内存、磁盘、网络、进程等数十种信息支持按快捷键切换视图。它还可以将数据捕获到文件然后用nmon analyser一个Excel表格生成漂亮的图表非常适合做单次性能测试的报告。glances是一个用Python编写的跨平台监控工具界面比htop更现代化信息也更全面。它可以通过CSV文件或API导出数据也支持客户端/服务器模式进行远程监控。对于需要同时关注多个指标的快速巡检glances非常高效。5.2 构建长期监控体系Prometheus Grafana对于生产环境我们需要一个7x24小时不间断的监控体系。PrometheusGrafana是目前最流行的组合之一。数据采集在需要监控的服务器上安装node_exporter。这是一个Prometheus的官方导出器它会收集系统的CPU、内存、磁盘、网络等几乎所有指标并通过HTTP接口默认端口9100暴露给Prometheus。数据抓取与存储Prometheus服务器定期如每15秒去拉取scrape所有node_exporter暴露的指标并存储在其内置的高效时间序列数据库中。可视化与告警Grafana连接到Prometheus作为数据源你可以利用其强大的仪表盘功能自由拖拽创建图表。例如创建一个仪表盘同时展示所有服务器的CPU使用率热力图、内存available趋势线、磁盘空间使用率饼图、以及核心业务磁盘的await延迟曲线。通过Grafana的告警规则你可以设置当某个指标超过阈值如available内存 1GB或磁盘await 50ms持续5分钟时自动发送通知到钉钉、企业微信或邮件。5.3 核心监控指标清单与告警策略根据经验以下是一些建议的核心监控项和告警阈值需根据实际业务调整监控指标采集命令/来源告警建议阈值说明CPU使用率node_exporter(100 - avg(rate(node_cpu_seconds_total{mode“idle”}[5m])) * 100) 855分钟平均使用率超85%CPU负载node_exporternode_load5 / count(node_cpu_seconds_total{mode“system”}) 35分钟负载超过核心数3倍可用内存node_exporternode_memory_MemAvailable_bytes / 1024^2 1024可用内存低于1GBSwap使用率node_exporterrate(node_vmstat_pswpin[5m]) 0 or rate(node_vmstat_pswpout[5m]) 0过去5分钟有任何Swap换入换出活动对于内存敏感型应用磁盘空间使用率node_exporter(node_filesystem_size_bytes - node_filesystem_free_bytes) / node_filesystem_size_bytes * 100 85使用率超85%磁盘Inode使用率node_exporter(node_filesystem_files - node_filesystem_files_free) / node_filesystem_files * 100 90Inode使用率超90%磁盘IO延迟node_exporterrate(node_disk_read_time_seconds_total[5m]) / rate(node_disk_reads_completed_total[5m]) 0.1读请求平均延迟超100ms0.1秒这套从命令行到可视化监控的完整技能栈能让你在任何Linux系统性能问题面前都做到心中有数手中有术。从快速响应到深度根因分析从单点排查到全局洞察这些工具就是你最可靠的伙伴。