站点跑了一段時間之後，訪問日誌、错誤日誌、缓存文件、备份包會一点点把磁盘吃掉。等到寫不進去的时候，表現往往不是“日誌报错”，而是資料库连不上、图片上传失敗、頁面直接报 500，排查时先要绕一大圈。把日誌轮轉和磁盘空間检查固定成日常動作，能省掉不少這類突發問题。
磁盘寫满时，最先出問题的是什么
- 資料库寫入失敗，會话或缓存無法落盘；
- 上传目錄寫不進新文件，後台發布内容卡在半路；
- 日誌繼續追加失敗，出错的現场反而看不到；
- 部分中間件直接拒绝請求，外部訪問统一报错。
這些現象看起来像程序缺陷，源头却常常在磁盘。所以先判断“是不是空間問题”，能避免在代碼里空找原因。
先做几項基础检查
- 分区使用率：用 df -h 看根分区和資料分区，注意資料盘和日誌盘是不是分開挂载的。
- inode 使用率：用 df -i 查看。小文件特別多时，空間還有余量但 inode 已经用尽，同样寫不進新文件。
- 增長最快的目錄：用 du 按层級排序，找出最近明顯變大的目錄，通常集中在日誌、缓存和备份三處。
- 大文件清單：找出單個几 GB 的日誌或备份包，這類文件往往是最直接的元凶。
- 日誌狀態：確認是否在压缩、是否按周期切分，還是所有日誌都堆在同一個文件里一直追加。
日誌轮轉的常见做法
按大小或按天切分
訪問量稳定的站点可以按天切分，流量波動大的更适合按大小切分，避免某天生成一個几 GB 的文件。两種方式也可以同时使用：達到指定体积或到了指定時間，任一條件满足就轮轉。
保留周期與压缩
保留份數要结合排查习惯来定。近期日誌建议保留 7 到 14 天，更早的可以用压缩包形式留存，或者直接归档到別的存储上。压缩後通常能省下大量空間，前提是別把压缩文件和原文件同时留在同一分区。
轮轉之後要让服務重新打開文件
日誌被移走或改名後，進程如果還握着原来的文件句柄，新日誌會繼續寫進已被刪除的文件，看起来像是“日誌不见了但空間没释放”。這種情况下需要在轮轉完成後触發一次重新打開日誌的動作，或者重载對應服務。
別把日誌删得太干净
出問题的时候，最近七到十四天的日誌往往是最有用的一段。清理之前先確認自己可能要查的時間范围，再决定删到哪一天。
顺手检查其他吃空間的地方
- 本地备份包：是否只保留最近几份，是否和站点資料放在同一块盘；
- Web 服務缓存與临时上传文件：上传被中断时容易留下半截文件；
- 應用缓存和舊版本發布目錄：每次發布都留一份，時間長了体量可观；
- 系統层面的临时文件和包管理缓存，也可以定期看一眼。
一個可执行的自查流程
- 记錄目前各分区與 inode 的使用率，作為基线，方便之後對比。
- 找出近期增長最快的目錄，確認是日誌、缓存還是备份造成的。
- 检查日誌轮轉配置是否真的生效，保留份數和压缩設定是否合理。
- 調整之後观察一個完整周期，確認切分、压缩、重载都正常。
- 给使用率設定阈值提醒，例如到 80% 提示、到 90% 告警。
- 把清理無用备份和临时文件寫進维護清單，按固定节奏执行。
小结
日誌和磁盘听起来是运维细节，但它直接决定蜘蛛和訪客能不能正常拿到頁面。把检查做成固定動作，成本遠低于事後救火。