远程登录服务器,敲下命令却面对一堆看不懂的数字，这种体验确实头疼。判断linux服务器是否健康，最直接的办法是组合使用free -h、df -h、top这三条命令，分别确认内存、磁盘和CPU负载，一张图就能看清服务器当前的压力。
会看linux服务器使用情况,不只是为了满足好奇心，排查线上故障、评估是否需要升级配置、判断是否存在入侵挖矿行为，全都依赖这些基础数据，掌握这套方法之后，你也能像老运维一样，三分钟定位问题根源。
linux服务器怎么看使用情况的基础命令
一条命令看整体负载：top
登录服务器之后,第一个建议敲的命令就是top，执行后屏幕上方会显示系统运行时间、登录用户数、平均负载，紧接着是CPU和内存的实时状态，整个过程是动态刷新的，相当于给服务器做了个实时体检。
重点看这几项数值：
- load average，即过去1分钟、5分钟、15分钟的平均负载，数值越接近0越好，如果持续大于CPU核心数，就说明系统忙不过来了
- %Cpu(s)，us表示用户态占用，sy表示系统内核占用，wa表示I/O等待，wa数值偏高，基本可以判断磁盘读写拖了后腿
- KiB Mem，总内存、已用、空闲、缓冲缓存，这里显示的不是全部真相，因为Linux会把空闲内存用作缓存，数据稍后在
free命令里验证
按下q键退出top，或者按数字1查看多核CPU每一个核心的使用情况，很多服务器整体CPU不高，但单核已经被打满，这是排查程序性能问题时的高频陷阱。
内存使用情况：free -h
free -h命令输出的数字，比top底部要清晰得多。-h参数的作用是人性化显示，自动把单位换算成G或M，不用自己心算字节换算关系。
关注倒数第二行：
- total，物理内存总量
- used，真正被程序占用的内存
- free，完全没被使用的内存
- buff/cache，Linux用来做磁盘缓存的部分，这部分内存会在程序申请内存时自动释放，不必视为可用内存的敌人
判断内存是否吃紧,业内专家建议使用共识标准：如果used + buff/cache长期接近total，但available（available列是系统估算的可启动新程序的内存）仍有一定余量，则系统还算健康，相反，如果swap（交换分区）开始持续占用，就说明物理内存已经严重不够用了。
磁盘占用：df -h 和 du -sh
磁盘是服务器的仓库,仓库满了，再好的CPU和内存也跑不动，用df -h查看分区整体使用情况，看的是挂载点和空间剩余。
重点关注根分区：
- Use%超过80%时，日志文件、临时文件、Docker镜像都会成为隐患
- 100%满盘则会导致数据库写入失败、网站session无法生成等连锁故障
定位大文件用du -sh /查看根目录下各个目录的体积，再逐层进入，比如du -sh /var/log/看日志目录里谁最占空间，数据盘和系统盘分挂载时，两道命令都要执行，避免只盯根分区而忽略数据盘写满的问题。
快速汇总清单
这里整理了一份linux服务器使用情况速查表,适合保存下来当备忘录：
| 查询需求 | 执行命令 | 核心观察指标 |
|---|---|---|
| 整体性能 | top |
load average、%Cpu(s)、KiB Mem |
| 内存细节 | free -h |
available、swap占用 |
| 磁盘空间 | df -h |
Use%、Mounted on |
| 目录体积 | du -sh 目录路径 |
各目录占用的总大小 |
| 网络连接 | ss -s |
当前TCP连接数、套接字统计 |
| 系统运行时长 | uptime |
平均负载 |
linux查看cpu内存命令，这些细节容易被忽略
CPU使用率怎么看才准确
top里显示的CPU百分比是瞬时值，偶尔看一眼会误判。正确姿势是执行top -b -n 2，让top采集两次数据后输出，查看第二次采样结果，第一次采样时系统会加载top自身进程，容易产生毛刺数据，第二次的结果更接近真实状态。
有个细节是,单核服务器的CPU 100%，在top里可能显示为100%，但如果是4核机器，一个核心满载整体显示可能只有25%，所以排查CPU瓶颈时，按1键确认单核占比，比只看整体数值更有价值。
如果不想手动刷新,vmstat 1 5命令可以每秒打印一次系统状态，连续打印5次，vmstat输出的us列和sy列与top的对应数据含义一致，而且输出格式更适合脚本采集。
内存到底够不够用
内存领域最常被误解的概念是buff/cache，Linux系统为了提高文件读写性能，会尽量把空闲内存用作缓存，这部分内存显示在free -h中就是buff/cache一列，当程序需要更多内存时，系统会自动释放缓存部分。
判断内存不足的可靠信号，是free -h输出中swap一栏的used数值。 假如swap used持续大于0，表示内核正在把内存页换出到磁盘，这时程序运行速度会明显下降，数据库类应用尤其敏感。
排查内存命令时很容易忽略大页内存（HugePages）的问题，需要查看cat /proc/meminfo中的HugePages_Total和HugePages_Free字段，数据库服务器如果配置了HugePages而进程没有绑定使用，会出现内存明明空闲、程序却申请不到内存的诡异问题，这类场景相对少见，但遇到了常规命令很难定位。
磁盘IO是不是瓶颈
磁盘IO问题的隐蔽性远高于CPU和内存,CPU使用率不高、内存也充足，但服务就是响应慢，此时怀疑点就在磁盘读写上。
执行iostat -x -k 2，查看%util列是否长时间接近100%，以及await列（平均I/O等待时间）是否明显高于svctm（服务时间）。%util接近100%说明磁盘设备已经接近饱和，await远大于svctm说明请求排队时间过长，两者同时出现基本坐实磁盘瓶颈，如果服务器没有安装sysstat包，先用apt install sysstat或yum install sysstat安装工具集。
linux服务器负载过高怎么办
先用uptime看平均负载
执行uptime，终端会显示负载数字，判断标准很简单：load average的三组数值，反映的是1分钟、5分钟、15分钟的平均负载趋势。
- 1分钟数值远高于15分钟数值,说明系统压力正在快速上升，需要立即处理
- 1分钟数值低于15分钟数值,说明压力正在减退，可能是之前有过一次任务高峰
- 三组数值都高,说明当前状况已经持续了一段时间，属于慢性超载
负载的数值需要结合CPU核心数解读,一台2核服务器负载到4已经属于超载，而16核服务器负载到8依然算轻载，判断前先数一下逻辑核心数，命令是nproc --all。
定位罪魁祸首
负载高的时候,top命令的用处发挥到极致，观察top输出进程中CPU占用率最高的那一个，通常是Java进程、PHP-FPM进程或者MySQL进程，然后根据进程特征做定向排查：
- 单个进程CPU持续高：可能是程序死循环或者算法效率低下，需要检查代码层面的逻辑
- 大量进程CPU均衡占用：常见于Web服务流量爆发，或者数据库密集查询，执行
ps -ef | grep php-fpm统计进程数量，判断是否启动过量worker - 僵尸进程（Z由僵尸状态标识）：数量多时说明父进程没有正确处理子进程退出，会占用进程表资源，需要重启父进程回收
找出可疑进程PID后,用top -p PID单独监控该进程的资源变化，或者用strace -p PID跟踪它所调用的系统接口，多数情况下，strace输出中反复出现同一个系统调用，就已经锁定了问题的核心位置。
典型处理方式
系统负载过高并非都是程序Bug带来的,不同原因应对完全不同：
- 内存不足导致频繁swap：需要扩容内存，或者优化程序内存占用，必要时调整swappiness参数（
sysctl vm.swappiness=10）让系统优先释放缓存 - 磁盘IO饱和：优化SQL语句减少全表扫描、把机械硬盘换固态硬盘、或者给数据库增加缓存层
- CPU密集型任务过长：检查是否有定时任务重叠执行，备份任务和高峰流量时间错峰
- 流量突发导致连接数暴涨：检查Web服务器配置的worker进程上限，考虑接入负载均衡器扩展后端节点
这些操作都需要在root权限下执行,修改系统配置前记得备份原文件，比较推荐的做法是先定位再动刀，任何盲目重启进程的行为都可能让正在执行的数据操作直接中断。
长期监控：从人工巡检变成自动化
用htop和nmon改善交互体验
htop是top的加强版，顶部有CPU和内存的彩色进度条，支持鼠标操作，还能直接按F9键对进程发送信号，Ubuntu系统一行命令装好：apt install htop，CentOS则需要先安装EPEL源。
nmon的功能更像一个缩小版的性能监测平台,按c键看CPU，按m键看内存，按d键看磁盘，运行nmon -f还能把数据保存成文件，后续用nmon analyser工具生成图表。
sar命令看历史数据
服务器凌晨崩溃,你早上才能到公司排查，这时候需要复盘昨夜的状态，sar命令可以帮你翻阅历史数据，追溯系统负载的变化轨迹：
sar -u # 查看CPU使用历史
sar -r # 查看内存使用历史
sar -b # 查看磁盘IO历史sysstat包会通过cron定时采集系统数据,默认保留最近7天的记录，查看昨天全天的CPU统计，执行sar -u -f /var/log/sysstat/sa$(date +%d -d yesterday)，最后的参数换成具体日期文件即可，这种回溯能力在企业服务器故障复盘时特别实用，不用依赖运维人员时刻盯在监控屏前。
把这些工具集成进crontab定时任务,执行频率按实际需求设定，生产环境建议维持每5分钟采集一次，数据量可控且足够细粒度，分析故障时能精确到具体时间点，配合企业微信或钉钉的webhook机器人，脚本检测到CPU连续多次超过阈值时自动发送告警，这已经属于初级运维系统的搭建思路了。
与linux服务器查看使用情况相关的频率最高问题
linux服务器卡顿，从哪里入手排查最快
先敲top看load average和CPU使用率，再敲free -h看内存是否耗尽，接着df -h确认磁盘有没有写满，三条命令走完，大体方向就能确定，如果都正常，排查网络层，用iftop看实时流量，或者确认是否在遭受CC攻击，大量半开连接会导致服务器响应缓慢。
free命令中buff/cache占用很高，内存是不是不够了
不是,buff/cache是Linux的磁盘缓存机制，目的是加速文件读写，当程序需要内存时，这部分会被自动回收，判断内存是否够用应当看available列，而不是free列，持续使用swap区才是内存不足的明确信号。
平均负载多少算正常
这是一个相对概念,基准是服务器的物理核心数，4核CPU的服务器，负载在4以下属于正常范围，达到8说明可能存在明显性能问题，达到12则基本处于过饱和状态，单看负载数字没有意义，需要结合核心数一起判断，行业共识认为长期超过核心数的70%就需要关注扩容或优化了。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/linux%e4%bd%bf%e7%94%a8%e6%83%85%e5%86%b5%e6%80%8e%e4%b9%88%e7%9c%8b%ef%bc%8c%e6%9c%8d%e5%8a%a1%e5%99%a8%e5%86%85%e5%ad%98%e5%8d%a0%e7%94%a8%e9%ab%98%e6%80%8e%e4%b9%88%e6%8e%92%e6%9f%a5%ef%bc%9f/
