(1)碎片的产生
1、db.collection.insert() 不断插入数据,扩展新的block,文件大小不断增大
2、db.collection.remove() 从集合中删除部分数据,很多block变成free,但物理空间并没有回收
3、db.runCommand({compact:"collection"}) 对集合执行compact,可以立即整理free的碎片空间
(2)compact操作对读写的影响
compact 一个集合,会加集合所在DB的互斥写锁,会导致该DB上所有的读写请求都阻塞;因为 compact 执行的时间可能很长,跟集合的数据量相关,所以强烈建议在业务低峰期执行,避免影响业务。
MongoDB 里删除一个集合里所有文档,有两种方式:
(1)db.collection.remove({}, {multi: true}),逐个文档从 btree 里删除,最后所有文档被删除,但文件物理空间不会被回收
(2)db.collection.drop() 删除集合的物理文件,空间立即被回收
总的来说,remove 会产生逻辑的空闲空间,这些空间能立即用于写入新数据,但文件占用的总物理空间不会立即回收;通常只要持续在写入数据,有物理空间碎片问题并不大,不需要去 compact 集合,有的场景,remove 了大量的数据后,后续的写入可能并不多,这时如果想回收空间,就需要显式的调用 compact。
Compact 动作最终由存储引擎 WiredTiger 完成,WiredTiger 在执行 compact 时,会不断将集合文件后面的数据往前面空闲的空间写,然后逐步 truancate 文件回收物理空间。每一轮 compact 前,WT 都会先检查是否符合 comapact 条件。
(1)前面80%的空间里,是否有20%的空闲空间,用于写入文件后面20%的数据
(2)或者前面90%的空间里,是否有10%的空闲空间,用于写入文件后面10%的数据
如果上面都不满足,说明执行compact肯定无法回收10%的物理空间,此时 compact 就回退出。所以有时候遇到对一个大集合进行 compact,compact立马就返回ok,集合的物理空间也没有变化,就是因为 WiredTiger 认为这个集合没有 compact 的必要。
The amount of empty space available for reuse by WiredTiger is reflected in the output of db.collection.stats() under the heading wiredTiger.block-manager.file bytes available for reuse.
> use ucloud # 批量插入数据 > for (var i = 1; i <= 1000000; i++) { db.starcto.insert( { x : i , name: "A", name1:"B", name2:"C", name3:"D"} ) } > db.starcto.count() 1000000 # 删除文档中记录 > for (var i = 1; i <= 500000; i++) { db.starcto.remove( { "name": "A"} ) } # 查看 starcto文档 当前可以回收空间 > db.starcto.stats().wiredTiger["block-manager"]["file bytes available for reuse"] 26173440
# 清理单点MongoDB节点碎片 > use db1 > db.runCommand({compact: "collection1"}) # 在副本集primary上执行需要加 force 选项 > use ucloud > db.runCommand({compact: "starcto", force: true}) { "ok" : 1 } # 查看空间释放情况(26173440 —> 4096) > db.starcto.stats().wiredTiger["block-manager"]["file bytes available for reuse"] 4096
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/128168.html
... compact操作步骤很多,但是可以有效减少磁盘使用量。 MongoDB与磁盘 当Fundebug处理的数据越来越多,这导致MongoDB的磁盘使用量越来越多,增长也越来越快。于是,我开始定时删除过期数据,优化算法减少冗余数据。但是,我发现...
...Serial一样是单线程,不同的是算法用的是标记-整理(Mark-Compact)。因为老年代里面对象的存活率高,如果依旧是用复制算法,需要复制的内容较多,性能较差。并且在极端情况下,当存活为100%时,没有办法用复制算法。所以需...
...候,寻找连续的内存空间会有难度。 3. 标记压缩(Mark-Compact) 老年代一般是由标记清除或者是标记清除与标记压缩的混合实现。 在整理压缩阶段,不再对标记的对像做回收,而是通过所有存活对像都向一端移动,然后直接清...
...率比较高的场景下是非常场景间。 标记-整理算法(Mark-Compact) 针对复制算法的两个缺点,在老年代一般会用这种标记-整理算法。 把存活的对象移到内存的一段,然后把剩余的空间全部清空掉。 分代收集算法 分代算法并不是...
...不适合。V8在老生代中的垃圾回收策略采用Mark-Sweep和Mark-Compact相结合 Mark-Sweep(标记清除) 标记清除分为标记和清除两个阶段。在标记阶段需要遍历堆中的所有对象,并标记那些活着的对象,然后进入清除阶段。在清除阶段总...
阅读 1036·2023-06-02 13:36
阅读 1509·2023-05-23 10:26
阅读 334·2023-05-23 10:25
阅读 994·2023-05-23 10:22
阅读 655·2023-05-23 10:18
阅读 589·2023-05-23 10:18
阅读 843·2023-05-17 10:18
阅读 1300·2023-05-17 10:16