Mongodb GridFS创建无限多的块并吃掉整个磁盘

我们有一个使用Java驱动程序将文件上传到GridFS的应用程序。在应用程序在生产环境中运行的6个月期间，我们遇到了这样一种情况：MongoDB数据库扩展到整个磁盘（1TB大小…数据库大小为30GB…大小大幅增加）。通过调查我们发现的原因，我们发现一个文件有2000万个fs.chunk，并且占用了磁盘。第二次（就在几天前），它为一个文件创建了4000万个块，并在磁盘已满的消息中崩溃。这些块没有fs.file记录，因此无法查看详细信息

服务器上运行MongoDB 3.2.5，所以我们升级到了最新的3.4.4版本。但是总的来说，有什么我们应该知道的问题吗？有没有一种方法可以配置MongoDB，使其不创建如此庞大的文件（每个文件的块数有一定的限制之类的）

编辑#1-其他详细信息

• fs.files计数：7800（平均每天删除旧文件，上载新文件）
• 平均文件大小：用户存储常见的MS Office文件，60-100kB，我们有几个更大的文件，大约100MB

用户使用web界面上传文件，该界面对上传大小有限制。所以没有人可以上传900GB的文件。。。我怀疑有人有一个。。。

---

在一段时间内，集合中也没有重命名或任何数据库维护，应用程序可以无缝工作。

您在GridFS中实际存储了什么？“文件”平均应该有多大？您希望存储多少“文件”？

fs.files

中的当前计数是多少，或者集合已重命名的任何内容。所以是文件集合，而不是块。如果你看不到我得出的结论，你可以看一些东西，然后在你的问题中添加信息。更新了我的帖子。当它第一次发生时，我们认为这是一种反常现象。但这是几天前第二次发生的，最大的问题是它占用了磁盘，处理1TB数据库的速度非常慢，删除坏块和修复db是个问题，因为它需要可用空间来缩小数据库等等。对于初学者来说，如果平均大小一直低于16MB，那么您可能不应该使用GridFS。如果您希望它在MongoDB中，而不是文件系统中，那么带有二进制数据的常规文档属性将为您省去很多麻烦。我想从这个卷中了解的一点是，您很可能会遇到逻辑故障，并且在实际更新内容时，您实际上正在创建新的文件/块。同样，滥用API也很容易留下孤立的块，因此一般的“小文件”似乎认为这里不应该使用GridFS。如果说贾斯汀·比伯（Justin Bieber）的话，那么你的100MB文件应该是“边缘案例”，在这种情况下，对这种使用有“特殊考虑”，而你处理的是“少量”与您处理大多数问题的方式不同。我明白您关于API使用等方面的观点。但在数千个文件上，一切都很正常。。。没问题。我的问题主要是，是否有人遇到过这种行为，MongoDB端是否有任何保护，或者在MongoDB上的一些旧版本中是否存在这样的错误（请参阅有关升级的信息）。我们刚刚尝试消除MongoDB问题。与此同时，我们正在调查我们的代码，以消除潜在的错误。