👁 105 次阅读

Dify 知识库存储为何删除数据集后仍显示 50/50 MB 满额？

来源链接：https://github.com/langgenius/dify/issues/37066

现象描述

一位 Dify Cloud（免费计划）用户报告，在新建工作区中导入少量小型 TXT 文件后，知识库存储（Knowledge Storage）显示 50/50 MB 已用尽，界面提示 “Vector Space is full”，导致无法继续导入新文档。该用户给出的关键观察点：

仅上传了几个小型 TXT 文件，其中一个约 2.7 MB。
文件总量远低于 50 MB 上限。
已删除工作区内全部数据集与文档。
删除后知识库存储仍显示 50/50 MB used。
“Vector Space is full” 提示持续存在。
退出登录再重新登录未能解决。
用户自行推测两种可能：删除数据集后存储未释放，或存储用量计算有误。

期望行为是：删除所有数据集与文档后，知识库用量应回归 0 MB（或反映真实剩余用量），”Vector Space is full” 提示应随之消失，只要总用量低于 50 MB 即可继续上传与处理文档。实际行为是：工作区为空时仍报告 50/50 MB used，上传与文档处理被阻塞。

背景原因

从 issue 讨论中维护者 hjlarry 的回应看，问题涉及两个层面。 用量计算存在长时间缓存。hjlarry 在 2026-06-05 首次回应时提到 “the vector space quota has some cache”；在 2026-06-10 的回复中进一步说明 “the usage calculation has a long time cache, we will fix it next version”。即向量空间配额与用量统计带有较长的缓存周期，删除操作不会立即反映到配额读数上。 部分情况下数据集与文档实际上未删除。在另一位用户 vivekvijayan7227-cmd 提供登录邮箱后，hjlarry 表示 “seems your datasets and documents haven’t been deleted, I can see there are 3 datasets”。针对发起者 ilievaina88 的邮箱（ina@i.gy），hjlarry 的观察是 “It seems you have 1 dataset and 1 document a few days before, and you delete the document and then delete the dataset quicklly ?”，即怀疑文档与数据集被快速连续删除，可能导致删除链路未走完。原文此处即为拼写笔误，保留字面写法。需要注意的是，讨论并未给出缓存的具体时长、作用范围或实现细节，该功能的具体实现尚未公开。issue 关闭原因为 not_planned，维护者明确未计划在框架层推进该修复，相关处理需要在应用层或基础设施层自行完成。

排查或量化方法

该 issue 的讨论中没有出现具体的命令行排查步骤或接口调用示例。hjlarry 的核对方式是直接查看用户账号下的数据集与文档数量，并据此判断数据是否真正被删除。讨论中可依据的定位信息包括：

配额读数与实际数据集/文档数量是否一致。
删除动作是否被执行完整（hjlarry 特别追问了 vivekvijayan7227-cmd “when do you remove them ?”，对方答复 “Today morning”）。
删除文档与删除数据集之间是否有足够间隔（hjlarry 对 ilievaina88 的疑问是两者是否被 “quicklly” 连续删除）。
是否刷新或重新登录后读数仍不变（用户已确认退出登录再登录无效）。

讨论中未提供用量重算接口、缓存清理命令或后台任务名称，官方也无实质修复方案，因此本节只归纳上述判断维度，不补写未在讨论中出现的操作步骤。

当前处理路径与局限

该 issue 由维护者判定为 not_planned 关闭，官方决定不在框架层推进，需要在应用层或基础设施层自行处理。讨论中实际出现的建议仅有以下内容，在应用该建议前需了解其局限。 向官方提供账号信息以人工核查。ilievaina88 与 vivekvijayan7227-cmd 均向 hjlarry 提供了登录邮箱，hjlarry 据此检查了各自账号下的数据集与文档数量。这是讨论中出现过的实际路径，但仅适用于 Dify Cloud，自托管场景无法依赖。 确认数据集与文档是否真正删除。hjlarry 对两位用户的核查结论都是”数据集/文档尚未删除”或删除时机存在问题。排查方向是确认删除动作是否完成，而不是反复刷新配额读数。 等待缓存过期或后续版本。hjlarry 表示 “we will fix it next version”，同时说明 “I’m not sure yet” 无法给出时间表。由于 issue 最终以 not_planned 关闭，这句话不能理解为修复已随版本发布，只能视为当时的回应。 局限说明：

维护者未给出缓存时长，用户侧无法预估何时能反映真实用量。
关闭原因决定该问题不会有官方框架层修复，缓存行为仍可能存在。
讨论中没有任何 PR 号或合并记录，因此不能声称代码已进主干或已含修复。
自托管用户在此 issue 中没有得到针对性的处理建议。

参数或对比表格

下表归纳讨论中两位用户与维护者的交互事实，用于对照定位。

用户	登录邮箱	维护者核查结论（据 issue 讨论）	用户侧已尝试的动作
ilievaina88	ina@i.gy	几天前有 1 个数据集和 1 个文档，文档删除后很快删除了数据集	删除全部数据集与文档、退出登录再登录，均无效
vivekvijayan7227-cmd	vivek.vijayan@nxtwave.co.in	可见 3 个数据集，数据集与文档尚未删除	表示当前文档总量不足 2 MB，当天上午已移除若干文档

hjlarry 对配额机制的两处说法：

2026-06-05：”the vector space quota has some cache”。
2026-06-10：”the usage calculation has a long time cache, we will fix it next version”。

两次说法一致指向缓存，但均未给出具体时长与清理方式。

常见错误排查

以下条目仅依据 issue 讨论中出现的动作与判断，未在讨论中出现的命令、脚本或工具不在其列。 1. 误以为删除即生效。hjlarry 核查 vivekvijayan7227-cmd 的账号后指出仍有 3 个数据集，与其”已删除”的描述不符。排查时应先确认数据集与文档是否确实移除，而非直接怀疑配额系统。 2. 删除顺序与间隔过短。hjlarry 对 ilievaina88 的判断是”删完文档后很快删除了数据集”。讨论中没有给出推荐的间隔时间，但该时序被维护者列为疑点。 3. 反复登录不解决缓存问题。用户明确反馈 “Logging out and back in did not resolve the issue”，重新登录不会绕过用量缓存。 4. 以界面读数判断真实用量。在缓存未过期前，界面上的 50/50 MB 不能代表删除后的真实占用，讨论中未提供其他查看真实用量的途径。 5. 在自托管环境套用 Cloud 的处理方式。讨论中的人工核查由维护者直接访问 Cloud 账号完成，自托管用户没有对应入口。

实践建议

结合讨论事实，可归纳以下做法。上传前规划用量。免费计划上限为 50 MB，用户上传的单个 TXT 文件约 2.7 MB，但读数显示 50/50 MB used，说明读数本身可能不可即时依赖。删除操作应确认完成。hjlarry 对两个账号的核查都指向”数据集或文档未真正删除”。删除数据集与文档后，建议确认移除结果，而非仅依赖界面读数变化。文档与数据集的删除不要连续紧凑执行。hjlarry 对 ilievaina88 的追问显示这一时序被维护者视为异常信号。关注官方后续说明。维护者提到 “we will fix it next version” 但无法给出时间表，且该 issue 以 not_planned 关闭。据 issue 讨论，缓存机制的行为仍需以实际版本表现为准，不应假定已修复。 Cloud 用户可准备账号信息。讨论中两位用户均通过提供登录邮箱让维护者完成核查，这是该 issue 中出现过的实际路径。自托管用户需自行在应用层或基础设施层处理。官方决定不在框架层推进，issue 中没有针对自托管的进一步说明。

FAQ

Q1：删除所有数据集后知识库仍显示 50/50 MB，是什么原因？ 据 issue 讨论，原因有两个方向。一是维护者 hjlarry 指出的配额缓存：”the vector space quota has some cache” 与 “the usage calculation has a long time cache”。二是维护者核查用户账号后发现数据集或文档实际未删除，例如对 vivekvijayan7227-cmd 的回复为 “I can see there are 3 datasets”。 Q2：退出登录再登录能刷新用量吗？ 不能。报告该问题的用户已尝试 “Logging out and back in did not resolve the issue”，读数仍为 50/50 MB，提示仍为 “Vector Space is full”。 Q3：这个问题已经被修复了吗？ 没有。该 issue 关闭原因为 not_planned，维护者明确不计划在框架层推进，需要在应用层或基础设施层自行处理。讨论中 hjlarry 提到的 “we will fix it next version” 无法给出时间表（”I’m not sure yet”），且没有出现 PR 号或合并记录，不能视为已修复。 Q4：缓存会持续多久？ 据 issue 讨论，hjlarry 只说明是 “a long time cache”，未给出具体时长、清理方式或重算接口。该功能的具体实现尚未公开。 Q5：自托管部署遇到同样现象怎么办？ issue 讨论中的人工核查由维护者对 Cloud 账号执行，自托管没有对应路径。hjlarry 对自托管场景没有给出建议，官方也未提交框架层修复，因此需要在应用层或基础设施层自行处理。