站点打不開或變慢，很多时候並不是流量突然暴涨，而是服務器上某個進程一直占着 CPU、内存或磁盘讀寫。對個人站長和小团队来说，這類問题最容易被忽略：頁面平时是好的，只是偶尔卡顿，等到某天备份脚本、图片压缩任務和抓取程序同时跑起来，整站响應就明顯變慢。
先分清是负载高，還是某個進程卡住
登入服務器後，不要急着重啟服務，先花几分钟看清現状。
- uptime：看 1、5、15 分钟的平均负载，和 CPU 核心數對比。單核机器负载長期超過 1、四核超過 4，就說明請求已经在排队。
- top 或 htop：按 CPU 與内存排序，记下占用最高的几個進程名和 PID。
- free -h：確認是内存不足導致 swap 频繁讀寫，還是單纯 CPU 被占满。
- iostat 或 iotop：看磁盘是否被大量寫入拖住，日誌、备份、資料库都可能出現在這里。
把這些信息连同時間点一起记錄下来。负载問题常常是間歇性的，两小时後再看可能一切正常，有歷史记錄才好判断規律。
常见的资源占用大戶
- 备份與打包脚本：压缩整站目錄、導出資料库，短時間吃掉大量 CPU 和磁盘 IO。
- 图片處理與缩略图生成：批量上传後一次性生成，容易長時間占用资源。
- 日誌切割與統計：單個日誌文件很大时，切割和压缩會明顯拖慢磁盘。
- 站内爬虫或自建抓取任務：不少运营工具直接在服務器上跑抓取，频率設定過高时相当于自己给自己加压。
- 資料库慢查询：一條语句掃全表，把连接數占满，表現出来就是整站變慢。
- 被掃描或異常請求：大量請求打到動態頁面，進程數迅速上升。
處理原則：限速、错峰、隔离
- 限速：给备份、压缩、抓取類任務加上並發上限，別让它們用满所有核心。命令行任務可以用 nice 或 ionice 降低優先級。
- 错峰：把重任務安排在訪問低谷，並让它們之間不要同时開始，例如备份和日誌切割間隔半小时以上。
- 隔离：能放到獨立進程或獨立机器上的任務就分出去，至少不要和 Web 服務抢同一份资源。
- 留出口：任何批量任務都要有超时和失敗登出机制，避免卡死在那里一直占着资源。
建立可重复的观察习惯
與其等出問题再排查，不如把观察固定下来：每天固定時間看一眼负载曲线和進程快照；给關键服務配置進程級监控，進程數、内存占用、响應時間超标时提前告警；每隔一段時間回看一次，看看哪些任務在悄悄變重，比如备份資料量變大、日誌增長加快、抓取任務的范围被改宽。
如果服務器上還跑着定时任務，建议把执行時間、预計耗时、资源占用情况记在一個简單的表里，新增任務时先對照一下，避免多個重任務挤在同一时段。
提示：不要用「重啟解决一切」的方式掩盖問题。重啟能让站点暂时恢复，但如果不找出是哪個進程、因為什么原因占用资源，同一個問题還會再来。排查過程留下的记錄，本身就是站点运营的一部分。