尽管运行repairDatabase（），但MongoDB不会回收空间

我们一直在一个非共享实例中运行mongoDB，只有一个数据库。数据文件的大小为0.45 GB。当我查看所有集合的storageSize时，总大小约为85MB。为了回收未使用的空间，我们运行了repairDatabase（），了解到文件大小从64增长到128，再增长到256，依此类推，直到2GB。由于我们拥有的mongo对象数据（85MB）可以容纳在64+128MB的文件中，因此我们希望回收256MB的文件。然而，令我们惊讶的是，没有回收任何空间

有人能告诉我们根据什么逻辑我们可以找到多少空间将被回收？从本质上讲，给定数据库占用的总磁盘空间，以及给定mongo对象数据的总大小，可以准确估计回收多少空间吗

以下是注释中请求的db.stats（）输出：

> db.stats()
{
        "db" : "analytics_data_1",
        "collections" : 12,
        "objects" : 207223,
        "avgObjSize" : 353.6659347659285,
        "dataSize" : 73287716,
        "storageSize" : 84250624,
        "numExtents" : 43,
        "indexes" : 26,
        "indexSize" : 21560112,
        "fileSize" : 469762048,
        "nsSizeMB" : 16,
        "dataFileVersion" : {
                "major" : 4,
                "minor" : 5
        },
        "ok" : 1
}
>

这意味着一个额外的文件总是预先分配的，一旦您开始写入它，

mongod

将预先分配下一个文件

修复不会回收通常存在的任何空间-只有在您删除了大量数据或删除了一些集合时，修复才会有所帮助

---

禁用预分配可以节省空间，但会降低性能，因为文件将在实际需要写入时进行分配，这将降低插入速度。

如果没有任何碎片（由于删除、文档移动等），则不会回收任何空间。为什么不向db.stats（）和单个集合stats提供输出？你凭什么认为有可回收的空间？不要忘记索引的空间。我已经添加了每个集合和索引的storageSize。相当于85MB。你知道预分配，对吗？前两个文件中都有数据，第三个文件是预分配的，这样当您填充128MB文件时，数据库就不必在等待下一个文件分配时暂停。@AsyaKamsky，让我知道以下是否正确：如果总数据大小为64+128+256+512+20，如果在这种情况下总文件大小为64+128+256+512+1024+2048，不会回收任何文件，因为预分配了一个额外的块。但是，如果总数据大小为64+128+256+512+20，如果在这种情况下总文件大小为64+128+256+512+1024+2048+2048，则将回收最后的2048MB文件。让我知道我的理解是否正确。最后一个（最大）文件总是空的。我不确定我是否能解析您的方程式，但如果您的数据需要两个数据文件，那么您将在目录中看到三个数据文件（除了.ns文件）。您能否分享一些关于noprealloc和SmallFile如何在生产中造成问题的链接？我们正在考虑在生产中使用它们的想法，但在继续之前要确保。noprealloc意味着，如果您正在写入5MB的数据，并且在4MB之后当前文件中的空间不足，那么在分配下一个文件时，写入操作将不得不阻塞并等待。使用prealloc，当您开始写入最后一个空文件时，它将在后台分配。因此，在生产中，当系统无响应时，这可能表现为偶尔但似乎随机的长时间暂停。SmallFile可能只会导致更多碎片，因为较大的集合和索引可能分散在多个文件（可能位于磁盘的不同部分）（关于SmallFile）但如果我们定期运行repairDatabase（），这不是可以纠正的吗？