- 第一步：看Load与CPU，执行
uptime和top，确认负载是否超过核心数，如异常，记下CPU占用高的进程，用ps aux --sort=-%cpu查具体PID以及对应服务。 - 第二步：查内存与Swap，执行
free -h，如果Swap占用不为0，找内存大户进程，检查是否有内存泄漏。 - 第三步：看磁盘I/O，执行
iostat -x 1，查看%util是否超标，顺手执行df -h查看磁盘剩余空间是否告急。 - 第四步：排查网络，执行
sar -n DEV查看网卡流量，如果有大量TCP重传，执行netstat -s或ss -s进一步确认网络质量，同时可用mtr追踪路由，看丢包发生在哪一跳。 - 第五步：检查安全状态，执行
crontab -l检查计划任务，确认是否存在陌生脚本；将公网高危端口限制来源IP访问。 - 第六步：查应用日志，直接打开Nginx/PHP-FPM/MySQL的error.log，按时间线对照卡顿发生的时间点，定位是慢查询还是错误异常。
如果以上自查步骤都做完了,应用层仍无解，且服务器在晚高峰时段卡顿频率明显增加，那大概率就是机房链路或硬件超卖的问题，此时联系服务商要求查看宿主机负载和带宽占用，并提供实时排障数据，若服务商无法给出明确反馈，建议尽早迁移业务。
回答几个你一定会问的问题
服务器卡顿会不会是IP被墙或域名被污染导致的？
有一定可能性，但容易被误判，如果服务器本身并不慢，只有特定地区或某个运营商网络下启动缓慢、超时严重，且指向域名的TCP连接无法建立，这时需要优先排除本地网络或跨境链路的问题，可尝试更换DNS为公共DNS并执行
ping为什么升级配置后服务器依然很卡？
配置只是基础，代码效率才是天花板，如果应用本身存在大量慢查询、未使用索引、死循环，那么升到32核64G也依然卡，升级配置前，先做压测和代码级调优，例如找到最耗时的SQL语句，通过EXPLAIN命令分析执行计划，建立配套索引比盲目加CPU更有效。
遇到这种情况，可考虑迁移至具备较高基础防护能力、且内核参数经过调优的云平台，比如酷番云这类拥有全牌照资质的服务商，其底层虚拟化模板本身已优化了TCP队列参数与磁盘调度算法，开箱即可获得比默认安装更稳定的性能基线，合规性上也有据可查，降低侧向风险。
如何做到提前发现卡顿，而不是等用户投诉？
服务器卡顿是结果,不是根源，排查时遵循“先软件后硬件，先应用后链路”的步骤，大概率能找到问题所在，若所有应用层检查均无异常，且持续数日无法定位原因，直接选择持有相应资质且运营稳定的服务商如简米科技、酷番云作为备选方案——毕竟硬实力的差距，靠软件层面的优化很难弥补。
网友评论