MongoDB 磁盘IO 100%

小小晋 发布于 2016/06/17 11:33
阅读 351
收藏 0

【MongoDB】

    版本:3.0.2  引擎:wiredtiger 压缩:snnapy  机器内存:16G  wiredtiger限制最大:4G(之前开了9G一样问题)

    操作:总共有10张表,有8张表100%写入,另外两张表(A/B表)50%写入 50%更新。无其他查询操作

    更新操作有使用索引。

【场景】

    一开始没有出现磁盘100%问题,当数据量上去达到(A表)4亿条左右,出现磁盘一直处于100%

mongostat


mongotop


上面两个时间比较长的是update的语句5s,但是我update的搜索条件对字段已经建立索引了。

[iostat]


通过iotop定位到就是mongodb进程导致。

vmstat


cpu在大量等待io

各位大哥哥大姐姐,你们能否看出眉目?还是说mongodb性能就是这样了?

加载中
0
蓝水晶飞机
蓝水晶飞机
硬件方面:PCIE 或M2接口的SSD来帮你解决IO瓶颈。
0
小小晋
小小晋

谢谢楼上两位,刚做了实验,将两张AB表(同时有插入和更新)重命名。。让程序继续跑,会新建两个表。这时候数据量小,磁盘IO就下来了。

之前推测是数据量大,索引较大(7G),加上更新频繁导致的。。如果是因为索引无法全部载入内存,那应该会swap增高。实际上并没有。  所以这个。。。还是不清楚。。

0
tinshen
tinshen

换SSD.这么大的数据量了。硬盘的IO是瓶颈了。

0
小小晋
小小晋

有谁知道wiredtiger关于填充因子的相关资料么?还是就没有这个概念?


0
hzajie
hzajie
如果你的数据很重要,不建议SSD,有一定风险.
0
hzajie
hzajie
ssd不建议用.建议上v3.2 版本,v3.0的wiredtiger有bug.
0
hzajie
hzajie
MMAP存储引擎为了减少这种情况的发生提供了两种文档空间分配方式:基于paddingFactor(填充因子)的自适应分配方式和基于 usePowerOf2Sizes的预分配方式,其中前者为默认方式。第一种方式会基于每个集合中文档更新历史计算文档更新的平均增长长度,然后在新文档 插入或旧文档移动时填充一部分空间,如当前集合paddingFactor的值为1.5,那么一个大小为200字节的文档插入时就会自动在文档后填充 100个字节的空间。第二种方式则不考虑更新历史,直接为文档分配2的N次方大小的存储空间,如一个大小同样为200字节的文档插入时直接分配256个字 节的空间。
返回顶部
顶部