进服务器就卡，绝大多数情况不是玄学，而是CPU、内存、磁盘IO或带宽中的某一个先被压垮了，按顺序排查这四项，十分钟内能找到病根。
一进服务器就卡？先分清是“进不去”还是“操作慢”
很多朋友说“服务器卡”，其实说的是两种完全不同的现象。第一种是远程连接都连不上，输入账号密码后界面一直转圈，或者直接超时。第二种是能连上，但敲个命令要等两三秒才回显，网站或游戏里的操作明显有延迟。
这两种情况的排查方向截然不同,连不上优先检查网络连通性、防火墙和安全组规则；连得上但慢，重点看系统资源消耗和进程状态，如果搞混了，很容易白折腾半天。
我的习惯是第一步先看网络，在你本地电脑上打开cmd，输入 ping 你的服务器IP -t，如果丢包率超过10%或者延迟波动剧烈，那基本是网络链路或机房出口的问题，跟服务器配置关系不大，如果ping值稳定在几十毫秒以内，那就继续往下看系统内部。
服务器卡顿排查步骤：从负载检查到进程优化
排除了网络因素后,登录服务器，按照下面这套步骤走一遍，基本能锁定问题。
先用三大命令看整体健康度
登录服务器后,二话不说，先跑三个命令：
uptime：看系统平均负载，这行输出最后有三个数字，分别代表1分钟、5分钟、15分钟的平均负载，如果三个数字都大于你服务器CPU核心数，说明系统已经忙不过来了；如果只是1分钟高、15分钟低，说明是突发流量或临时任务导致的。top：看实时资源占用，按大写P按CPU排序，按大写M按内存排序，重点看%CPU和%MEM两列，哪个进程长期霸占资源，哪个就是嫌疑犯。free -h：看内存余量，注意看available那一列，这才是真实可用的内存，如果available长期低于总内存的20%，就得考虑加内存或者优化应用了。
CPU跑满怎么定位进程
如果是CPU问题,在top里按P排序后，记下PID，然后跑top -p PID单独盯它，行业共识认为，持续CPU占用超过95%的进程，要么是死循环，要么是单线程处理能力到了极限。
常见元凶是这几个：
- MySQL或者其他数据库：慢查询成片出现。
- PHP-FPM或Java应用：并发请求堆积，线程池被打满。
- Spawn出的僵尸进程：父进程没回收子进程，导致进程表膨胀。
定位到了,看具体类型再处理，比如PHP-FPM跑满，可以先重启一下服务验证是不是缓存问题，systemctl restart php-fpm；如果是数据库慢查询，进MySQL跑SHOW PROCESSLIST;，看哪些SQL执行时间特别长，然后针对性加索引。
内存吃紧别急着加内存条
free -h看到内存几乎耗尽，很多人的第一反应是升配，但先别急，看两个东西：
swap分区是否被大量使用，如果swap的si和so列持续有数值，说明物理内存确实不够了，开始用磁盘当内存了，这种情况卡是必然的，因为磁盘读写速度比内存慢几个数量级。- 是不是有缓存机制在吞内存,Linux的机制是空闲内存尽量用来做文件缓存，
free -h里buff/cache列如果是几十G，不代表不够用，只要available充足就没问题，别被缓存吓到了。
真正确认内存不足,处理方式是：重启常驻内存的大应用（比如Java的JVM堆设置是否合理，默认最大堆是不是设太高了），清理无用进程，最后才考虑升级配置。
服务器卡顿最常见的是磁盘和带宽，别都怪CPU
很多朋友一卡就觉得CPU弱,实际上更多的卡顿来自磁盘读写瓶颈和带宽跑满，这两个是隐蔽杀手，排查起来需要多两步。
磁盘IO成为瓶颈的典型症状
操作服务器时,输入命令后有明显的“迟滞感”，但是看CPU和内存都挺闲，这时候八成是磁盘IO在拖后腿，使用iostat -x 1查看，重点看%util这一列，如果数值长期接近100%，说明磁盘已经满负荷运转了。
举一个实际场景：你搭建的网站访问量稍微上来一点，页面加载就开始变慢，上传图片时尤其明显，要转好几秒，看CPU占用才30%，内存还剩很多，但磁盘的%util顶到90%以上，这种就是磁盘读写速度不够了。
解决方法按性价比排序：
- 优化读写频率：把日志写入频率调低，或者把数据库的sync_binlog参数从1改成0或2，牺牲极少量可靠性换明显写入性能提升。
- 换SSD：如果服务器还是机械硬盘，提升会非常直观。
- 加缓存层：对热点数据使用Redis做缓存，减少对磁盘的直接读取。
带宽跑满的识别与处理
很多朋友问“服务器进游戏就卡是配置不够吗”，其实相当一部分情况是带宽被吃满了，正常CPU和内存都没问题，但访问一高就卡，用iftop或nload看一下实时带宽，如果流量已经顶到了购买带宽的上限，那就要么升级带宽，要么做流量优化，启用Gzip压缩、优化图片体积、把静态资源丢到CDN，都是常用手段。
业内专家指出，中小型网站遇到的首个性能瓶颈，多不在CPU和内存，而在带宽和磁盘IO，因为配置买高了看着浪费，带宽却常常被忽视。
游戏服务器卡顿优化：按场景逐一击破
很多玩家朋友用的是云服务器开游戏服,比如Minecraft或者幻兽帕鲁这类，这类场景的卡顿比较特殊，不同于网站，有独特的排查重点。
玩家多就卡，怎么破
如果你发现只有在线人数超过某个阈值（比如10人、20人）才开始卡，那就是典型的多线程并发瓶颈，游戏服务器的逻辑线程通常是单线程的，也就是所谓的主线程，CPU的单核性能决定了能带动多少玩家，看top的时候留意一下CPU核心的使用率，如果总使用率不高，但某个核心已经100%，那就是单核瓶颈。
处理方法：
- 把服务端进程的CPU亲和性绑定到性能最好的核心上。
- 调低游戏内的实体运算频率、怪物刷新密度。
- 升级CPU型号时,优先看单核主频，而不是核心数量。
开了Mod或插件后卡顿
这种情况最常见,装了插件后，服务器卡顿，多数是插件代码问题或者内存分配不足，检查服务端目录下的报错日志，以及/gc或/tps这类查询TPS的命令，TPS长期低于15（正常是20），说明服务端已经严重过载，关掉可疑插件逐个排除，把JVM参数里最大堆内存调高到物理内存的50%-70%。
服务器卡顿怎么排查最有效？日常预防优于事后补救
等卡了再去排查,终究是被动挨打，养成习惯，把预防做在前面，能省掉大部分半夜爬起来处理故障的精力。
装一个自带监控的运维面板
推荐装宝塔面板或者1Panel,装好后它们自带资源监控图表，能保留最近几天的CPU、内存、磁盘和带宽曲线。这个功能非常有用当服务器卡的时候，不用凭感觉猜，直接翻几十分钟前的曲线，看看是哪个指标先异常的。
写个简单的脚本定期自查
运维面板能看整体,但进程细节还得靠命令，写一个简单的Shell脚本，定时把关键指标写入日志文件，卡的时候翻日志：
#!/bin/bash echo "=== $(date) ===" >> /var/log/server_check.log uptime >> /var/log/server_check.log top -bn1 | head -20 >> /var/log/server_check.log free -h >> /var/log/server_check.log
用crontab设置每5分钟执行一次,日志保留一周，遇到卡顿直接tail -100看最近的输出，比临时登录强多了。
定期重启是笨但管用的土办法
对很多中小应用来说,跑一两个月不重启，各种资源泄露和碎片化会累积，选取低峰期每周定时重启一次核心服务，成本极低，但能解决很大一部分“慢到要重启才能缓解”的卡顿问题。
常见问题解答
一进服务器就卡，为什么重启后又好了？
重启相当于把长期运行的进程状态全部清空,内存碎片、未释放的文件句柄、僵死的网络连接、累积的CPU占用异常，全部归零，如果重启后恢复流畅，说明系统本身存在资源泄漏或进程积累问题，建议排查是否有应用长期运行未优化，或者定时任务过于频繁。
服务器配置很高，但还是一进就卡，问题出在哪？
排除配置因素后,优先怀疑三点：带宽被打满（下载流量、被恶意攻击）、磁盘IOPS不足（高并发小文件读写时尤其明显）、安全组或防火墙规则异常（导致每次请求都要额外等待超时），用iftop看带宽，用iostat看IOPS，最后检查防火墙日志。
进服务器就卡的情况下，怎么快速判断是本地网络还是服务器问题？
在本地电脑上开三个终端,分别执行ping、tracert和ssh连接到服务器，如果ping延迟极低但ssh很慢，问题在服务器本身或ssh服务配置；如果ping延迟高且丢包，问题在本地网络或机房链路；tracert输出中某一段延迟暴涨，说明瓶颈在中间路由节点。
服务器卡顿并不可怕,可怕的是没有章法地乱试，记住这个顺序：先看网络，再看负载，然后分攻CPU、内存、磁盘、带宽四个方向，大多数情况下，你花十分钟按照这套流程走一遍，比闭着眼睛乱搜教程高效得多。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787163.html
