先沿着业务请求找出空间从哪里增长

一次常见的业务请求会经过应用处理、写入访问日志或错误日志，并可能产生数据库记录、索引、临时文件和队列数据。请求量上升时，日志通常较快增加；订单、用户资料等业务数据则会长期累积；并发升高还可能带来更多临时文件、缓存或任务积压。因此，Linux服务器磁盘空间不足处理不能只看当前还剩多少空间，应按“已用空间＋预测增长＋峰值临时占用＋运行余量”规划，并分别核算日志、业务数据和备份。

运维人员可以先确认空间究竟被哪个挂载点、目录或文件类型占用，再用近期日增长量和业务增长量预测未来保留周期内的需求。日志容量主要受请求量、单条日志大小、保留天数和压缩效果影响；业务数据主要受新增记录、索引及数据库自身文件增长影响；并发量则用于评估临时空间和突发峰值，不能直接等同于磁盘需求。

先确认空间瓶颈在哪个文件系统

先检查挂载点、文件系统容量和 inode。容量尚有余量但 inode 用尽时，大量小文件同样会导致创建文件失败。

df -hT
df -i

df -hT显示各挂载点的总量、已用量、可用量和文件系统类型；df -i检查 inode 使用情况。判断时要看业务数据实际所在的挂载点：例如日志目录、数据库目录可能分别挂载，根分区有空间不代表数据库所在分区也有空间。

接下来查看目录占用。以下命令适用于常见的 GNU du 环境，-x表示不跨越到其他文件系统：

sudo du -x -h --max-depth=1 /var 2>/dev/null | sort -h
sudo du -x -h --max-depth=1 /var/log 2>/dev/null | sort -h

将 /var替换为实际数据目录。若目录统计结果与 df已用量相差较大，可能是权限不足、挂载边界不同，或文件已删除但仍被进程打开。可在安装了 lsof 的系统上检查后一种情况：

sudo lsof +L1

如果发现大型已删除文件仍被进程占用，空间通常要等相应进程关闭文件后才释放。不要为了立即腾空间就直接重启关键服务；先确认进程、文件用途和业务影响，再按服务维护流程处理。日志目录统计也应区分当前日志、轮转日志、压缩包和其他业务文件，避免把不同增长来源混在一起。

把日志增长换算成容量

日志估算应尽量基于实际观测，而不是仅按服务器规格推算。选取具有代表性的统计窗口，记录每天请求数、日志目录净增长量，以及错误日志、审计日志等独立类别的变化。遇到促销、批处理或周期性任务时，应纳入峰值日期；只有平稳工作日的数据，可能低估高峰期需求。

简单估算可以使用以下关系：

日志日增长量 ≈ 日请求量 × 平均每次请求产生的日志字节数 ＋ 非请求类日志增长量

保留期所需空间 ≈ 日志日增长量 × 保留天数 ÷ 实测压缩系数

这里的压缩系数应按实际轮转文件计算：压缩前大小除以压缩后大小。若不同日志类型差异明显，应分别计算，而不是给所有日志套用同一个比例。采样日志、错误堆栈和调试日志的单次写入量可能远大于普通访问记录；开启详细日志后，即使请求量不变，增长速度也可能明显改变。

请求量可从应用监控、访问日志统计或业务指标中取得。若只能查看日志文件大小，应比较相邻时段的净增量，并确认期间没有轮转、压缩、清理或迁移，否则文件大小变化不等于真实产生量。日志格式调整、字段增加或错误率变化后，也应重新测量平均每次请求的日志量。

保留期限应由业务排障、审计和合规要求共同确定，不宜为了短期腾空间而直接删除历史日志。若保留期较长，可评估压缩、分区存放或归档策略；实施前应确认检索时效、归档位置和恢复流程。轮转配置还要检查是否确实生效，以及服务是否会继续向旧文件写入。

将请求、并发和业务数据分别纳入预测

请求量和并发量对磁盘的作用不同。请求量通常决定一段时间内产生多少访问日志和业务记录；并发量更多影响同一时刻的缓存、临时文件、上传暂存区、任务队列和数据库临时空间。并发升高不必然按比例增加持久数据，但峰值并发可能让临时空间在短时间内达到高位。

业务数据可按实际增长趋势估算。对于新增记录型业务，可用“每日新增记录数 × 单条记录及相关索引的实际平均占用”估算数据文件增量，再与数据库文件或数据目录的观测增长交叉验证。若有更新、删除、索引重建、事务日志或批量导入，目录增长可能与新增记录数不呈线性关系，应把这些操作周期纳入观察。不同数据库的存储机制不同，不应只用表面记录大小推算磁盘占用。

预测时建议拆成以下几项：

• 当前持久数据：应用文件、数据库数据、索引及需要保留的历史文件。
• 日志增长：按实测日增量和保留期限计算，并区分压缩前后占用。
• 临时峰值：观察批处理、上传、导入、排序、索引维护等任务期间的最高额外占用。
• 备份占用：确认备份是否写在同一文件系统。若同盘保存，备份文件必须计入容量；若保存到其他位置，也要单独核算其目标存储和保留策略。
• 增长余量：为业务增长预测偏差、临时异常和扩容操作留出空间，避免文件系统接近满载后才处理。

可以用下式建立统一的容量账：

规划容量 ≥ 当前已用空间 ＋ 预测周期内新增数据 ＋ 同盘备份增量 ＋ 峰值临时占用 ＋ 运行余量

其中“预测周期”应覆盖从发现容量风险到完成扩容或清理策略调整所需的时间。运行余量不是适用于所有业务的固定百分比，应根据增长波动、扩容响应时间、文件系统特性和业务故障容忍度设定，并通过监控验证。对增长快、波动大的业务，余量通常要比稳定的小型业务更充足。

如果业务记录与请求量高度相关，可用请求量预测记录增长；如果请求主要是查询，业务数据增幅则可能很小，但访问日志仍会增长。反过来，批量导入可能在请求量不高时带来明显的数据文件和临时空间增长。规划时应分别测量，不能用单一“每个用户占多少空间”覆盖所有场景。

形成可执行的容量计划

运维人员可以按以下步骤完成一次基线测量和预测：

1. 确认挂载关系。用 df -hT、df -i核对日志、数据库、应用文件和备份分别位于哪个挂载点，记录各自可用空间及 inode 状态。
2. 建立占用清单。用 du定位主要目录，结合文件类型区分日志、数据库、临时文件和备份。对统计不一致的情况，检查权限、文件系统边界及已删除但仍打开的文件。
3. 测量实际增长。在覆盖正常流量与业务高峰的观察窗口内，记录每天请求量、各类日志净增长、数据库目录变化和临时空间峰值。标注发布、导入、批处理等特殊事件。
4. 按保留期预测。分别计算各类日志的保留量、业务数据增长、同盘备份和峰值临时占用。压缩收益和数据库增长参数使用实测值；没有足够观测数据时，先标注估算不确定性，并增加监测频率。
5. 确定触发条件。为各挂载点设置空间和 inode 告警，并结合增长速度判断剩余时间。可按“可用空间 ÷ 近期日增长量”估算空间耗尽时间，但若增长有明显周期，应使用包含高峰的窗口计算，不能把短期均值当作长期保证。
6. 复核并更新。业务请求量、日志级别、保留要求、数据库结构或备份策略变化后，重新核算。新增容量后也要复查挂载点、应用写入路径和监控，确认空间确实加到了瓶颈文件系统上。

监控不仅要看剩余容量，还要看增长趋势。容量告警用于发现接近阈值的挂载点；增长速率用于判断还能支撑多久；inode 告警用于发现小文件耗尽风险。若磁盘空间充足但业务写入仍慢或失败，应继续检查磁盘 I/O、文件权限、只读挂载、应用限制等因素，不能把所有写入故障都归因于容量不足。

方案选择与适用边界

如果主要增长来自日志，优先核对日志级别、轮转、压缩和保留策略；若日志保留要求不能缩短，则要为所需周期准备相应空间或规划归档。若业务数据持续增长，应根据数据目录的趋势增加对应文件系统容量，并核查数据库和应用是否支持目标挂载方式。若临时文件或备份造成周期性峰值，则应把峰值纳入容量账，而不是只按月末平均用量配置。

如果已用空间突然增加，先定位新增文件和产生它的进程，再确认是正常流量、错误重试、异常日志量、备份堆积还是业务数据变化。不要仅凭文件名判断可删；删除日志、数据库文件或备份前，应确认保留要求、备份完整性和恢复可用性。任何清理操作都要明确影响目录和文件范围，先保留必要副本，并准备在误删或业务受影响时恢复。对由进程持续持有的文件，直接删除文件路径也未必释放空间。

扩容是否有效，取决于空间是否落在实际写入的挂载点，以及应用、数据库和文件系统能否正确使用新增容量。扩容后可重新运行 df -hT、df -i，对照原先记录确认容量和 inode 状态；随后观察一段业务高峰，检查增长速率、临时峰值和告警是否符合预测。容量规划解决的是空间不足风险，不替代对磁盘读写性能、数据库锁等待或应用故障的诊断。

按业务变化持续修正容量

当请求量平稳、日志策略固定且数据增长容易预测时，按周期复核日增量和保留期通常足以支持容量安排；当并发波动明显、批处理集中或业务数据快速累积时，应提高监测频率，并把峰值任务单独纳入评估。最终容量取决于日志产生量、业务数据规模、保留要求、临时峰值、备份位置和扩容响应时间。

运维人员下一步可以先为每个挂载点建立“当前占用、日增长、峰值占用、保留要求、预计可支撑时间”的记录。数据足以解释增长来源时，再选择调整日志策略、归档、迁移数据或扩容；若增长来源尚不明确，应先定位目录和进程，避免通过盲目删除或单纯增加容量掩盖持续增长的问题。