服务器占用率高，本质上是计算资源被某个或某几个进程抢占，再往下挖，是业务代码、系统配置或攻击流量在作怪，解决问题靠的是排查路径而非盲目重启。
服务器占用的直接受害者是CPU、内存、带宽和磁盘I/O，这四兄弟只要有一个被拖垮，整台机器就跟着遭殃，大多数运维新手的第一反应是重启大法，但治标不治本，要真正搞定它，得按下面这条主线往下摸。
服务器cpu占用率过高怎么办
CPU是服务器的大脑,它喊累的时候，业务通常已经卡成幻灯片，常见原因集中在三个方向：业务流量突增、代码死循环、恶意挖矿程序。
先分清是用户多还是程序傻
打开监控面板,如果CPU曲线是平滑爬升，大概率是真实流量上来了，比如抢购活动、营销热点带来的并发，这种情况不用慌，加带宽、扩节点是正道，如果曲线是锯齿状暴涨暴跌，或者高峰期在凌晨两三点，那基本可以怀疑是程序逻辑问题或外部入侵。
用top命令锁定元凶
登录服务器,执行top，按下大写字母P按CPU排序，看第3行和第4行的us（用户态）占比和sy（内核态）占比。
- us特别高：你的业务进程在疯狂计算，检查代码里有没有死循环、正则灾难性回溯、或者大集合遍历。
- sy特别高：问题出在内核层面，常见于文件系统锁冲突、网络软中断风暴，执行
vmstat 1看cs（上下文切换）列，数值若几十万，说明进程切换太频繁，典型症状是线程池开太大或锁竞争严重。
云服务器cpu占用100%正常吗
分情况,如果是新部署的应用正在编译、镜像构建、或者数据库刚启动在做缓存预热，短时间100%反而说明资源用上了，正常，但如果持续10分钟以上，且业务并无对应操作，那就不正常，行业共识认为，持续100%超过5分钟就该介入排查，超过15分钟基本可以断定有问题。
服务器内存占用高怎么排查
内存占满的症状比CPU更隐蔽,通常先表现为Swap读写暴涨，随后服务假死，原因绕不开三个：缓存命中率低、内存泄漏、单个进程过度申请。
先看总量，再看进程，最后看缓存
执行free -h，注意available（可用）这一列，而不是只看used，Linux会把空闲内存拿去当文件缓存，这个buff/cache很大是好事，不用慌，真正要警惕的是available接近0。
接着用ps aux --sort=-%mem | head -10查进程，重点看RSS（常驻内存）列，Java系应用如果堆设置得比物理内存还大，必然导致内存溢出，查JVM堆参数用jmap -heap pid，Python脚本则要小心全局对象不断往列表里塞数据。
Swap占用高的隐患
当你发现free -h里Swap used超过总Swap的30%，说明物理内存已经兜不住了，此时应用每次读写内存都要走一遍磁盘，响应时间直接翻十倍甚至上百倍，排查方向是找出跑Swap的进程，用for i in /proc/[0-9]/status这类命令遍历进程的VmSwap字段，一抓一个准。
服务器带宽占用率高如何解决
带宽被打满的表现很纯粹网页加载慢、视频转圈、SSH操作像放幻灯片，原因分为外部攻击和内部失控两类。
外部攻击型：流量清洗是第一优先级
如果vnstat或云监控显示入方向流量突增到平时几十倍，同时CPU并不高，那多半是DDoS或CC攻击，这时别纠结于封IP，先打开云服务商的流量清洗开关，或者接入高防IP，等攻击流量被挡在门外，再慢慢分析攻击特征。
内部失控型：查连接数和流量大户
用iftop看实时带宽消耗，记下占用最高的IP和端口，然后执行ss -antp查对应端口，看是不是有服务在向外疯狂发包，常见事故有：日志采集Agent批量回传历史数据、数据库备份任务压到业务高峰期、有人把服务器当网盘存了一堆大文件。
数据库服务器cpu占用率高的原因
这类服务器的CPU异常要单独说,因为它没有复杂业务代码，锅基本在SQL上。
- 慢查询堆积：执行
show processlist;，看看有没有一堆State为Copying to tmp table或Sending data的会话。 - 索引失效：表数据量大，但查询字段没建索引，全表扫描直接打满CPU，用
explain select...看执行计划，重点是type列，如果是ALL（全表扫描），就需要优化。 - 并发连接数过高：连接池配置过大，CPU都耗在线程切换上，控制
max_connections，配合慢查询日志slow_query_log定位具体的拖后腿SQL。
磁盘I/O占用：被忽略的第三只老虎
CPU和内存都正常,但服务器就是慢，这时候要查磁盘，原因通常有三个：随机读写太高、Swap读写频繁、日志写入量大。
用iostat和iotop把现场抓出来
执行iostat -x 1，看%util列，如果接近100%，意味着磁盘已经处于饱和状态，再看await列，数值超过几十毫秒说明响应已经拉胯。
紧接着用iotop看是哪个进程在猛写盘，绝大多数情况是日志在刷屏，比如某个业务接口报错后疯狂打印堆栈，或者数据库的binlog同步被卡住，处理方式是调整日志级别、拆分大日志文件，或者给磁盘做读写分离。
云盘还牵扯到IOPS和吞吐量的区别
如果你用的是云服务器,记得看一眼云盘类型是高效云盘还是ESSD，ESSD主打高IOPS，适合数据库；高效云盘主打吞吐，适合备份存储，当你在ESSD上跑了大文件传输，IOPS指标可能不高，但吞吐跑满一样会卡。
从原因到落地的排查工具箱
与其记一堆零散命令,不如把这个排查顺序背下来：先看负载，再排进程，最后查IO和网络。
按这个顺序执行
- 第一步：
uptime看系统负载（load average），负载超过CPU核数的70%就该介入。 - 第二步：
top排序CPU和内存，记住高占用进程的PID。 - 第三步：
pidstat -p PID 1观察该进程的CPU和内存曲线是平稳还是持续的。 - 第四步：
strace -p PID跟着进程走，看它卡在哪个系统调用上，比如卡在futex是锁等待，卡在read是等网络或磁盘。
把罪魁祸首“请出去”
确认是无用进程后,kill -15 PID先优雅终止，不行再kill -9 PID，但注意，如果是数据库实例或核心消息队列，先尝试重启该服务而非直接杀进程，杀完之后，去排查为什么它会跑到那个状态。
服务器占用问题Q&A
服务器日常CPU占用多少算健康？
看业务类型,日常负载在10%-30%之间属于舒适区，预留了应对突发流量的空间，长期稳定在70%以上，说明资源接近瓶颈，建议扩容或优化代码，若长期接近100%且伴有响应变慢，优先排查代码质量和外部攻击。
如何用一句话向老板汇报服务器占用高的原因？
直接说结论：“服务器资源不够用了，原因是某个具体进程占用了具体数量的资源，触发条件是某个具体业务动作，解决方案是优化或扩容。”给老板看原因，别让他看命令。
服务器占用本质是资源供需失衡,排查时记住一个核心原则：先抓进程，再谈扩容，最后调配置，按文中的命令路径逐步操作，多数问题能在半小时内定位根因，剩下的事情就是改写代码或升级资源了。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/775352.html
