站点访问变慢时，很多人的第一反应是重启服务或升级配置。但如果没找到根因，重启只能换来短暂恢复，过一会儿又慢。对搜索引擎蜘蛛来说，响应时间过长会降低抓取意愿；对用户来说，等待几秒就会离开。排查服务器资源和响应时间，应该按“先定位范围、再看资源、再看数据库、最后回到代码”的顺序来。
先判断是整站慢还是局部慢
不要一上来就翻代码。先确认慢的范围：是首页、列表页、详情页都慢，还是只有某个栏目、某个接口慢。打开监控工具，看响应时间曲线、错误率和流量是否同时变化。
- 如果全站都慢，优先怀疑服务器资源、数据库连接或网络出口。
- 如果只有部分页面慢，可能是该页面的查询、模板逻辑或第三方接口。
- 如果蜘蛛抓取时慢、用户访问正常，可能是抓取频次过高或动态页缓存未命中。
服务器资源：CPU、内存、磁盘 IO
CPU 持续偏高
常见原因包括：某个脚本死循环、被恶意请求刷接口、定时任务重叠执行、图片压缩或视频转码占用。可以用 top 或云监控查看具体进程。若是 Web 进程占满，再去看访问日志里是否有异常高频 IP 或异常 URL。
内存吃紧
内存不足会触发 swap，磁盘 IO 随之升高。检查应用进程是否有内存泄漏、缓存是否设置得过大、数据库连接是否及时释放。如果缓存占用持续增长，需要设置合理过期策略，而不是无限扩容。
磁盘 IO 高
日志写入频繁、数据库全表扫描、备份任务跑在高峰期，都会推高磁盘 IO。可以把访问日志按天切割，数据库备份放到凌晨，并检查慢查询。磁盘空间接近满时，写入性能也会明显下降。
数据库慢查询往往才是真凶
页面渲染快，不代表数据库轻松。很多站点慢在几条没有索引的 SQL 上。建议开启慢查询日志，按耗时排序，逐条分析。
- 找出执行次数多、单次耗时长的 SQL。
- 用 EXPLAIN 查看是否走索引，重点看 type 和 rows。
- 为 WHERE、ORDER BY、JOIN 涉及的字段补充合适索引，避免盲目加索引。
- 检查分页写法，避免大偏移量查询；可以用游标或范围条件替代。
- 确认是否有重复查询，同一请求内能缓存的就不要再查。
Web 服务进程与缓存
应用进程数、连接数和超时设置不匹配，也会让响应时间变长。比如应用进程太少，请求排队；进程太多，数据库连接被占满。缓存命中率低时，每次请求都穿透到数据库，同样会拖慢整站。
- 检查应用进程、线程和数据库连接池的上限与当前使用量。
- 检查 Redis、Memcached 或文件缓存的命中率和内存占用。
- 确认缓存键是否合理，是否存在大量无效缓存或缓存雪崩。
- 静态资源交给 CDN 或 Web 服务器处理，减少应用进程压力。
建议的排查顺序
- 看监控：响应时间、CPU、内存、磁盘 IO、数据库连接数。
- 定位时间段：是持续慢，还是某个时间点开始慢。
- 看访问日志和错误日志：是否有异常请求、超时、500 错误。
- 看数据库：慢查询、锁等待、连接数。
- 看代码和配置：最近是否上线新功能、改过模板或缓存策略。
排查完记得记录基线：正常情况下的 CPU、内存、响应时间大概是多少。没有基线，就很难判断“现在到底算不算异常”。
站点性能问题不一定要靠升级配置解决。先把范围缩小，再沿着资源、数据库、进程、缓存的顺序查一遍，往往能定位到真正的原因。日常维护比事后救火更重要。