Performance paddingFactor是否使我的更新变慢？
我有一个mongodb实例，db名称：“bnccdb”，集合名称：“AnalysizedLiterture”，文档大小：600万。此外，始终有一个轻量级后台守护进程，用于从internet抓取数据并插入此集合（插入频率非常低，大约每秒插入1-2个文档，因此对数据库性能几乎没有影响） 请参阅此集合的配置信息： 它表明填充因子非常接近2.0 现在，我有另一个过程，该操作为集合中的每个文档添加两个键。但遗憾的是，更新操作非常慢。这真的让我感到困惑。当此更新过程运行时，mongostat输出为： 您可以看到，故障和锁定数据库的结果非常高，这意味着数据库工作负载非常高 我真的找不到原因。我怀疑，因为总是有一个轻量级守护进程将数据插入此集合，所以mongodb将paddingFactor从1更改为更大的值（1.9..。而且由于paddingFactor非常高，每次我的进程都会执行更新操作（为每个文档添加两个键），db将回收磁盘空间用于填充，从而产生较大的读/写开销。 谁能给我一些建议？Performance paddingFactor是否使我的更新变慢？,performance,mongodb,padding,updates,Performance,Mongodb,Padding,Updates,我有一个mongodb实例，db名称：“bnccdb”，集合名称：“AnalysizedLiterture”，文档大小：600万。此外，始终有一个轻量级后台守护进程，用于从internet抓取数据并插入此集合（插入频率非常低，大约每秒插入1-2个文档，因此对数据库性能几乎没有影响） 请参阅此集合的配置信息： 它表明填充因子非常接近2.0 现在，我有另一个过程，该操作为集合中的每个文档添加两个键。但遗憾的是，更新操作非常慢。这真的让我感到困惑。当此更新过程运行时，mongostat输出为： 您
请。您的填充因子如此之高的原因是因为您的更新。MongoDB使用此值“过度分配”用于存储文档的空间，以便在不需要移动到MongoDB存储系统中的更大空间的情况下对文档进行更新和增长。这意味着您的更新一直在增长文档，需要将文档从磁盘上的现有空间中拉出并移动到另一个新的更大空间。旧空间将留给r电子化使用，但通常不会尽可能有效地重复使用 填充因子为2意味着MongoDB为每个文档分配了两倍的空间，这表明您的系统执行了大量的更新和移动
您应该考虑启用，这将使您的空间分配统一，从而更好地重复使用空间。启用此设置后，您应该重新同步或修复数据库以从头开始重建它，因为新的分配系统只会影响新文档。我真的怀疑此解决方案，因为我的userFlags以前是1，not 0。我将其设置为0以测试这是否会加快更新速度。但我从未修复过我的数据库。是的。因此，我将首先将userFlags设置为1，然后修复数据库？因为我的数据库是单个实例，而不是群集，所以我不需要重新同步，对吗？如果您有单个实例，那么是的。您将需要修复而不是重新同步。您的问题与移动存储中的文档，与两次更新相比，这是一项昂贵的任务。此外，所有页面错误都表明MongoDB正在从磁盘中提取您的数据以完成查询/更新。这也是延迟的一个重要原因。我没有像您告诉我的那样。我相信问题已经因为您而得到解决r解决方案。非常感谢。您的更新速度很慢，因为您在此集合中有25个索引。出于相同的原因，您的插入速度很慢。您的RAM中驻留的索引不足5GB，而您的索引为30GB（数据为20GB）。当您有如此多的页面错误时，为什么您希望它会很快？