云服务器 100G 硬盘半年就满了？六类占用、五个隐形增长与五条自查

「我这台机器 100G 硬盘，装个网站怎么半年就满了」——这个问题在「小硬盘机器」上极其常见，而答案往往不是「存的东西多」，而是有几样东西在后台默默长大。而它们长大时不会报警，只会某一天让服务突然停掉。这篇把「硬盘被谁吃掉」这件事拆成六类占用、四个清理动作、以及一条「多久会满」的估算线，最后给一份五分钟能跑完的自查命令清单。

五款高性价比档位速查

有需要云服务器的，可以先看这一张表——五个价位段每款都是高性价比，价格从 22 元拉到 480 元。

商家	推荐款	配置	带宽与流量	月费	核心特点
云途	HK.N4.A	2 核 2G 20G	200Mbps / 500G	22 元	三项都在合理区间的入门档
isvoro	HK CN2 Core	2 核 2G 30G	100Mbps / 300G	25 元	硬盘 30G 加 CN2 回国线路
rabisu	Aydn VPS x8	4 核 8G 60G	—	34.5 元	每核 8.6 元，带宽需单独确认
zji	香港 BGP 在售机型	6 核 16G 480G	55Mbps / 1T	450 元	480G 硬盘是整机档里少见的大盘
sixtynet	LAX-MEDIUM	8 核 8G 160G	10Gbps / 20T	480 元	唯一「大端口配大配额」的组合

补一句：「100G」这个数字本身也有水分。

格式化后可用通常只有九成多。

所以「100G 的盘」实际大概能用 93G 左右,这个落差要先扣掉。

一、硬盘被六类东西吃掉

还有一个「第七类」：「已删除但未释放」。

文件删了，但空间没回来。

而因为「有进程还开着它」。

所以「df 和 du 对不上」这个现象,答案就在这一条。而它的排查方法是「看打开的文件句柄」,不是「继续删文件」。所以「盘满但找不到大文件」这种情况,要先想到这一条。而这个坑几乎每个运维都踩过,原因就是「不知道有这一层」。

判断方法：df 和 du 的结果对不上就是它。

而<'isvoro'+'> 那种小档位，一旦碰上这一条最难受——因为余量本来就少。

再看一个「日志进程」的典型场景。

日志被「切走」但进程还写着旧文件。

所以「切日志要通知进程重开」。

还有一条：「重启进程」也能释放。

但那是「最后手段」。

再看「inode」这一项。

它和「空间」是两个独立的上限。

所以「空间还够但写不进去」要查 inode。

七类里前六类是「占用」，第七类是「假占用」。

而「假占用」最容易让人误判成「买大盘」。

一块 100G 的盘，会被六类占用分摊。

类别	典型占用	增长方式
系统与软件	8 到 15G	一次性
日志	每天几十到几百兆	持续
数据库	看数据量	持续
上传文件	看用户量	持续
缓存与临时	几百兆到几 G	波动
镜像与备份	每个几 G	堆积

这张表最该注意的是第二行「日志」：它是最容易被忽略但增长最快的一类。

因为它「看不出在长」。

所以「硬盘突然满」这件事九成不是「业务存储多了」，而是「日志和缓存没人管」。而这两类占了「可清理」部分的绝大部分。所以「盘满」的第一反应不该是「买大盘」，而是「看看日志有多大」。而这一步一条命令就能查出来。

第一行系统。它是一次性的。

而「软件装多了」会让它慢慢涨。

第三行数据库。它是「真正需要」的部分。

而「binlog 和慢日志」也会算在里面。

第四行上传。它是最该迁出去的一类。

而「对象存储」比「加硬盘」便宜得多。

第六行镜像。它是最容易「堆积」的一类。

而<'isvoro'+'> 那种 30G 的入门档，这一类的管理必须严格。

补一个「日志总量」的量级。

一个中等流量的站点,访问日志每天几百兆。

一个月就是十几 G。

所以「20G 的盘」光日志就能吃掉大半。

补一句：「日志轮转」要「按大小 + 按时间」双条件。

只按时间切，突发时会在一天内写满。

二、日志是最容易被忽略的一类

再说一个「日志级别」的实际影响。

debug 和 info 的差距可能是十倍。

而「生产环境开 debug」是常见错误。

所以「把日志级别降下来」这个动作,能立竿见影地把增长速度压下去。而它几乎没有副作用——因为「排查用 info 就够」。所以「日志」这一项的处理顺序是「先降级,再轮转,最后清理」。而这个顺序的成本是从低到高。而多数人是「直接清理」,治标不治本。

判断方法：看当前配置的日志级别。

而<'云途'+'> 那种 20G 档位，降级几乎是必须的。

再看一个「框架日志」。

有的框架默认打得很详细。

所以「框架自己的配置」也要一并检查。

还有一条：「异常日志」会重复打。

一个死循环能刷满盘。

再看「访问日志」的格式。

记「响应体」会暴涨。

所以「只记头部字段」其实就够用了。

再看「压缩」。

归档日志压缩后只剩百分之几。

所以「压缩存档」是性价比最高的做法。

日志之所以难发现，是因为它「分散」。

系统日志、应用日志、访问日志，三处各长各的。

而每一处单看都不大。

所以「查硬盘」不能只查一个目录，要「按目录大小排序看前几名」。而排在第几位的往往就是你没想到的那个。所以第一条排查命令不该是「看总用量」，而是「找出最大的目录」。而这一步能立刻指向真正的原因。

判断方法：按目录大小看前十。

而<'云途'+'> 那种 20G 档位，日志管理是「能不能用满一年」的关键。

再看一个「日志轮转」的配置。

按天切、保留七天、压缩存档。

所以「保留七天」通常已经够排查用了。

还有一条：「日志级别」也要降。

生产环境不必开 debug。

再看「访问日志」。

它是增长最快的一项。

所以「关掉或不记响应体」能省很多。

再说一个「用户上传」的处理。

上传文件是「最该搬走」的一类。

而「搬走」比「加盘」便宜得多。

所以「上传走对象存储」这件事,对「小盘机器」几乎是必需的。因为「上传量」不可控——它随用户增长而增长,而「日志」至少能限速。所以「不可控的增长」这种数据,应该放在「能弹性扩的地方」。而这个逻辑决定了「哪些数据该留在机器上」。而多数人是「先存本地,满了再说」。

判断方法：问「上传量会不会随用户涨」。

而<'云途'+'> 那种 20G 档位，上传基本必须外置。

再看一个「缩略图」的生成。

它可以「按需生成 + 缓存」。

所以「不预生成全部」能省很多。

还有一条：「原图」和「缩略图」分开存。

否则清理时会互相牵连。

再看「删除」的机制。

「软删除」会占着空间。

所以「定期硬删」要做。

补一句：「清理脚本」要「先查再删」。

直接删的话就有可能误伤正在被使用的文件。

三、缓存和临时文件也在长

再说一个「包管理器缓存」的量级。

它可能累积到几个 G。

而「装过很多软件」的机器尤其明显。

所以「清包缓存」这件事在大机器上确实无所谓,可在小机器上能腾出一成空间。而它是一条命令的事。所以「空间不够」的时候,先跑几条清理命令,往往就够用了。而这个动作花不了一分钟。而多数人直接跳到「扩容」。

判断方法：清包缓存和旧内核。

而<'rabisu'+'> 那种 60G 档位，这一步不急但值得做。

再看一个「临时目录」。

上传中断会留下残片。

所以「按时间自动清理」比「手动翻找」可靠得多。

还有一条：「会话文件」最好外置。

否则它会随访问量线性涨。

再看「缩略图缓存」。

图片站最容易堆积这一项。

所以「定期重建」这种做法比「永久保留」省得多。

第二类隐形占用，是「缓存和临时」。

包缓存、镜像层、临时上传、会话文件。

而它们「平时不显眼」。

所以「盘满」这件事有一个规律：真正需要保留的数据往往只占三成，剩下七成是可清理的。而「可清理」的部分需要「定期清」而不是「一次性清」。所以配一个「每周自动清理」比「一次大扫除」更重要。而这个动作在很多地方被当成可选项。

判断方法：清包缓存、清镜像、清临时。

而<'rabisu'+'> 那种 60G 档位，清理压力小一些。

再看一个「镜像层」的占用。

多次构建会留下旧层。

所以「定期 prune」是常规动作。

还有一条：「临时上传」要设过期。

否则它们会永久留存。

再看「会话文件」。

它随访问量增长。

所以「会话外置」也能省硬盘。

再说一个「VACUUM 与 OPTIMIZE」的概念。

删除后留下的空洞需要「整理」才回收。

而不同的数据库命令名称不同。

所以「删了数据盘没变小」这件事不是bug,是「机制」。而「整理」这个动作在大表上可能锁表,所以要选低峰。所以「数据库清理」这件事的风险比「清日志」高得多。而这就是「清理优先级」里把它排在后面的原因。而「先清日志」这个顺序能避免「为了一点空间去锁表」。

判断方法：查「表大小与行数」是否匹配。

而<'rabisu'+'> 那种 60G 档位，这一步的紧迫性低于小盘。

再看一个「归档」的做法。

把旧数据「挪走」而不是「删掉」。

所以「归档」能兼顾「省空间」和「留证据」。

还有一条：「归档到对象存储」最划算。

因为它比加盘便宜。

再看「定期任务」。

「每月归档一次」是常见频率。

所以「定时做」比「想起来才做」可靠。

补一句：「备份」不要和「库」放同一块盘。

否则「盘满」会同时失去「数据」和「备份」。

四、数据库的膨胀与清理

再说一个「表分区」的思路。

按时间分区能让「删除旧数据」变快。

而「删整块」比「删行」省事得多。

所以「日志表按月分区」这件事,能把「清理」从「跑几小时」变成「删一整个分区」。而这个设计在「日志类数据」上收益最大。所以「表结构」这件事一开始就要为「以后怎么删」考虑。而多数人是「先建表,以后再说」,结果清理变成苦差事。

判断方法：看「最大的表是不是按时间增长」。

而<'zji'+'> 那种 480G 大盘，分区的好处没那么急。

再看一个「索引膨胀」。

重建索引能回收一部分空间。

所以「定期重建索引」也是一件常规动作。

还有一条：「大字段」要单独存。

否则「查一行」会读很多无用数据。

再看「历史数据归档」。

把「一年前的」挪到别的表。

所以「归档」这个做法比「直接删除」更有价值。

第三类，是「数据库本身」。

数据表会涨，索引会涨，日志也会涨。

而「删了数据」不等于「盘变小」。

所以「数据库占了几 G」这个问题的答案,有一半是「删掉的东西留下的空洞」。而这类空洞需要「整理」才会回收。所以「表里只有十万行却占了五 G」这种情况很常见。而这个认知能解释「为什么清了数据盘还是满」。

判断方法：看「表大小」和「行数」的比例。

而<'zji'+'> 那种 480G 大盘整机，数据库膨胀的压力最小。

再看一个「binlog」的占用。

它可能比数据本身还大。

所以「保留几天」要设。

还有一条：「慢日志」也会长。

而它排查完就该关。

再看「备份」。

本地备份和数据库在同一块盘上。

所以「备份到异盘或异地」是必要。

再说一个「监控」的具体做法。

每天记一个「已用百分比」就够。

而「七天的斜率」能看出趋势。

所以「监控硬盘」不需要复杂工具,一个定时脚本加一个日志文件就够。而这个数据的价值在于「它比单次 df 更有信息量」——因为「趋势」能预测「什么时候满」,而「单点」不能。所以「记录」这一步比「告警」更基础。而它几乎零成本。

判断方法：每天记一次百分比。

而<'isvoro'+'> 那种 30G 档位，这个记录几乎是必须的。

再看一个「周对比」。

「本周比上周多用了多少」。

所以「周期性对比」比「绝对值」更有用。

还有一条：「突发增长」要单独标出来。

因为那是「异常」而不是「趋势」。

再看「告警阈值」。

70%、85%、95% 三档。

所以「70% 就该动手」。

补一句：「剩余天数」低于 30 天就该动手。

而这个阈值和「清理周期」要匹配。

五、多久会满：一条估算线

再说一个「增长曲线」的形状。

它通常不是直线，而是「阶梯」。

而「每次业务变化会跳一截」。

所以「按直线外推」会低估。因为「新增一个功能」可能带一个新的日志源。所以「剩余天数」的估算要「按月复算」,而不是「算一次用一年」。而这个复算动作能在「跳变」发生时及时看到。而多数人是「算一次就放心了」,结果在跳变后措手不及。

判断方法：每月对比「日增」的变化。

而<'sixtynet'+'> 那种 160G 档位，即使跳变也有缓冲。

再看一个「清理后的回落」。

「清理一次」能让曲线掉一截。

所以「有没有定期清理」这一点,会明显改变曲线的形状。

还有一条：「清理」的成本也要算。

「每周半小时」这件事本身也是一种支出。

再看「自动化」。

「自动清理」能把这笔成本压到接近于零。

所以「配一次定时任务」比「每周手动清」划算。

「还能撑多久」这个问题，可以算。

每天新增量 ÷ 剩余空间 = 天数。

而「每天新增」要看「日志 + 数据 + 上传」三项。

所以「还能撑多久」这个数字应该被算出来，而不是「等它满」。因为「满」的那一刻服务会直接不可用，而「算出来」的那一天还来得及扩。所以「每月算一次剩余天数」这件事，是小硬盘机器的必做项。而它只需要两个数：剩余空间和日增。

判断方法：剩余 ÷ 日增 = 天数。

而<'sixtynet'+'> 那种 160G 档位，剩余天数通常宽裕。

再看一个「日增」的取法。

用「七天的平均」而不是「某一天」。

所以「周末和工作日」要一起算。

还有一条：「保留 20% 余量」是安全线。

因为「写满」之后系统会出各种怪问题。

再看「增长突变」。

「日增突然翻倍」通常意味着出了问题。

所以「日增」本身也是个监控项。

再给一个「清理优先级」的排序。

先降日志级别、再开轮转、再清缓存、最后归档旧数据。

而「删业务数据」排最后。

这个顺序的依据是「可逆性」:前几项都是「可恢复的清理」,而「删业务数据」不可逆。所以「盘满」时的正确做法是「按可逆性从高到低清理」,而不是「看谁占得多」。因为「占得多的可能是你必须留的」。而这个顺序能避免「为了腾空间而误删」。而误删的代价远大于「买一块大盘」。

判断方法：按「能不能恢复」排序再动手。

而<'spartanhost'+'> 那种大端口档，硬盘宽裕时也建议保持这个习惯。

再看一个「清理记录」。

记下「清了什么、腾了多少」。

所以「下次遇到就快得多」。

还有一条：「清理脚本」要版本化。

否则「改了哪里」会忘。

再看「验证」这一环。

清理后用 df 确认。

所以「清了但没腾出」要查第七类。

再看「告警」。

70% 就该开始清理。

而「等 95%」已经太晚。

再说一个「清理后的验证」。

清完要「再跑一次 df」确认数字掉了。

而「没掉」通常就是第七类。

所以「清理」不是一个动作,而是「动作 + 验证」。而缺了验证,就会误以为「清了没用」,进而去做「买大盘」这种更贵的动作。而这个「清理—验证—再判断」的循环,能把绝大多数「盘满」问题在「免费」这一步解决。而它只需要多敲一条命令。

判断方法：清理前后各跑一次 df。

而<'zji'+'> 那种大盘机器，验证这一步同样值得做。

再看一个「释放句柄」的做法。

重启「持有该文件的进程」。

所以「重启进程」有时候是唯一能生效的解法。

还有一条：「重启」要在低峰。

因为它会短暂中断服务。

再看「长期」的做法。

「切日志后通知进程重开」。

所以「配置对」比「重启」更根本。

补一句：「五条命令」要存成一个脚本。

这样「下次遇到盘满」就不用从头再想一遍。

再补一个「换大盘还是继续清」的判断。

看「清理后的稳定水位」。

清完稳定在六成以下，说明「清得过来」，不必换盘；

清完一周又回到八成，说明「增长大于清理」，该换盘或外置。

这个判断的依据是「清理能不能跟上增长」。而「跟不上」才是「该换盘」的真正理由，而不是「盘满了」。因为「盘满」是结果，「跟不上」是原因。所以「换不换盘」这个问题，答案在「清理后的水位」这个数上。而这个数只要一周就能观察到。

判断方法：清完观察一周的水位。

而<'isvoro'+'> 那种 30G 档位，通常是「该外置」而不是「该换盘」。

再看一个「外置」的成本。

对象存储按量付费,小量很便宜。

所以「外置」往往比「换大盘」更省。

还有一条：「外置」也要考虑「访问延迟」。

而它对「静态资源」影响不大。

六、五分钟自查清单

五条命令，五分钟能跑完。

第一条：看总量与可用。

第二条：按目录大小看前十。

第三条：看日志目录的总量。

第四条：看 inode 使用率。

第五条：看「已删除但未释放」的句柄。

五条里第五条最容易被忽略但最诡异：它的表现是「删了文件但空间没回来」。因为「进程还持有那个文件的句柄」。所以「删了不生效」这个现象要查「打开的句柄」而不是「继续删」。而这个坑几乎每个运维都踩过一次。

第一条。它排除「还早」的情况。

而<'spartanhost'+'> 那种大端口档，硬盘这一侧通常不是瓶颈。

第二条。它直接指向原因。

第四条。它排除「小文件太多」。

最后回到开头：「100G 半年就满」这件事，八成是「日志和缓存」而不是「业务数据」。

而五条命令跑一遍，原因就出来了。而在此之前「买大盘」是最贵的那个选择。

本文讨论服务器硬盘空间的占用来源与排查方法，不针对任何具体商家，也不对任何产品的硬盘性能或容量真实性作评价与承诺。文中提到的六类占用、四个清理动作与五条自查命令均为通用运维参考；实际占用取决于系统版本、软件配置、业务形态与日志级别，同一容量在不同环境下消耗速度可能相差很大。文中所有估算（如「8 到 15G」「保留 20% 余量」）均为经验参考值，非实测结论或行业标准。本文不构成任何购买建议，亦不代表本站立场。因依据本文内容进行清理或采购决定所产生的直接或间接损失，作者及本站不承担任何责任。