站点訪問變慢时，很多人的第一反應是重啟服務或升級配置。但如果没找到根因，重啟只能換来短暂恢复，過一會儿又慢。對搜尋引擎蜘蛛来说，响應時間過長會降低抓取意愿；對用戶来说，等待几秒就會离開。排查服務器资源和响應時間，應该按“先定位范围、再看资源、再看資料库、最後回到代碼”的顺序来。
先判断是整站慢還是局部慢
不要一上来就翻代碼。先確認慢的范围：是首頁、列表頁、詳情頁都慢，還是只有某個栏目、某個接口慢。打開监控工具，看响應時間曲线、错誤率和流量是否同时變化。
- 如果全站都慢，優先怀疑服務器资源、資料库连接或網絡出口。
- 如果只有部分頁面慢，可能是该頁面的查询、模板逻辑或第三方接口。
- 如果蜘蛛抓取时慢、用戶訪問正常，可能是抓取频次過高或動態頁缓存未命中。
服務器资源：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、内存、响應時間大概是多少。没有基线，就很难判断“現在到底算不算異常”。
站点性能問题不一定要靠升級配置解决。先把范围缩小，再沿着资源、資料库、進程、缓存的顺序查一遍，往往能定位到真正的原因。日常维護比事後救火更重要。