MongoDB 的磁盘 IO 高到被 Linode 警告..

linode没有用cgroup限制么？ 还是没用cfq
那lz用cfq和cgroup吧。

+ redius 减少磁盘IO

mongo疯吃IO就是内存太小, 装不下热数据, 要再redis不是OOM, 就是mongo让出部分内存, 自己对IO吃得更厉害, 这是往死里做啊.

碰到过，原因就是内存不够用，解决办法只有加内存。

@notnumb 使用cgroup这样去限制不会影响网站的速度吗？我是希望能从应用的层面来处理,比如通过iotop观察到一次查询瞬时300M/s的disk read 这是我的文档结构设计得不合理吗？

@skybr
@kslr
- -# 除了加内存就没有别的活路了啊？

@undeflife 换mysql

@skybr
@undeflife
@wecoders
话说，你们在技术选型的时候是怎么决定用mysql还是用mongodb的？

@missdeer 用你搞得定的技术；以及前期的成本考虑；

你确定是mongodb导致的嘛

@missdeer 单机mongo意义不大吧，还不如很多包装的leveldb或者mysql或者Elasticsearch

@jungledrum iotop活动前三都是mongodb的进程

@undeflife 暂未找到。

一天6000PV，平均每分钟4.2PV，这能把linode的IO跑成abuse，不容易吧？

比如有正确添加索引都会出现这种状况。
另外 Linode 的警告只是提醒下你，你可以修改其上限的。

看错了，abuse ticket确实有点夸张了。

估计是数据库结构或者用法不正确。MongoDB 要正确使用其实很有难度。

@msg7086
insert query update delete getmore command flushes mapped vsize res faults locked db idx miss % qr|qw ar|aw netIn netOut conn time
1 4 *0 *0 0 1|0 0 7.95g 16.1g 2.82g 1046 site:0.1% 0 0|0 1|0 4k 3k 17 14:06:33

mapped 近8G vsize 16G
4G的vps 而mongodb的数据文件也已经涨到8G了,按楼上的回复 应该是内存不足导致的.

@msg7086 PV貌似不是这么算的，有的时间人很多，有的时候基本没人
一般很大部分都集中在某几个小时里面

确实需要+内存了

我不太清楚你的程序有多大的查询量，也不太清楚mongodb的运行性能到底如何，不过我这跑的论坛，12G的MySQL配合memcache热备，用20刀的机器就能轻松顶下来了，一天200万pv。

而且之前搜索的时候也的确看到有人抱怨说mongodb的内存缓存需要等预热时间，否则会死很惨，不知道有没有关系。

另外推荐改善一下架构，能走缓存的就不要撞数据库了。如果nosql的索引做不好的话，还是回到RDBMS的世界来比较好，毕竟是非常成熟的架构。

@tonyluj 对于大部分应用，一小时6000pv都不是什么很大的量，每秒2个而已。纯SSD+E5-2680v2要是每秒2个pv都应付不下来，肯定是有什么问题了。

@msg7086 考虑迁到postgreSQL上去,这样部分数据结构的问题可以使用PostgreSQL的json字段的特性解决,只不过这个需要开发时间,我现在需要解决掉这个高IO的问题,还不知道我如果持续不解决,Linode会怎么处理

@undeflife mongodb我不熟所以没办法帮你。

Linode如果abuse的话是停掉你的机子直到你能解决问题为止。

会不会是journal日志的影响

@codingpp 有过这个怀疑 但是不敢关闭 - -

@undeflife 没办法, mongo的性能和可靠性本身就高度依赖充足的内存和冗余的节点来保证.


@missdeer 有nosql需求的还是走pg吧, hstore很靠谱, 9.4之后还有jsonb.

mongostat

看一下faults数目，正常情况下应该为0的。如果持续大于0说明一直在换页，该加内存了。如果持续100+，iostat看下IO负载，绝对要加内存了。

@undeflife
用了journal日志也会丢消息吧，mongo又不支持事务，journal刷新磁盘默认好像是100ms，这100ms内的日志还会丢
把journal日志关掉，就是把这100ms变成了60s

前天写个用mongo的程序，数据文件300m，journal日志3g，过不了几天我的小vps就没空间了。。。

@happy123
@codingpp
faults 4～15 所以还是内存的问题..我准备晚上试试 repairDatabase 这样数据文件能变得小一些 看有没有效果.

这个4g内存，8g数据怎么会有那么高的fault，是不是索引建的有问题啊？或者是数据结构问题，每次查询都要调入所有数据到内存？

你这fault是1046么？！！

@sujin190 找到个坑...程序上有个地方无索引的排序整个大collection，把这个语句干掉之后似乎情况好了不少...

@undeflife 8g，应该还不到百万条记录吧

@sujin190 嗯 不到 90几万

1.加索引
2.加内存
3.换成支持数据压缩的TokuMX