环境:mongoDB2.6.8 集群,
下午突然发现4个从节点,挂了3个,全都都出现以下提示:
2016-03-11T16:53:02.483+0800 [conn312773] Assertion: 13548:BufBuilder attempted to grow() to 134217728 bytes, past the 64MB limit.
经分析, [conn312773] 连接前面的查询 全是统计分析类的查询,后跟开发部确认。
他们自己认为是以下查询 有问题。
这里不太常用到的是: item:{$push:"
}
}
])
我们的解决方法:
把item 中$push 的值从总条记录,修改到只返回某几个字段(尽量少,同时不要返回子文档及数组,因为这两种类型很难预见有多大)
再把查询条件优化成最小,每次只查询少量数据。从而减少返回的数据量。
下午突然发现4个从节点,挂了3个,全都都出现以下提示:
2016-03-11T16:53:02.483+0800 [conn312773] Assertion: 13548:BufBuilder attempted to grow() to 134217728 bytes, past the 64MB limit.
经分析, [conn312773] 连接前面的查询 全是统计分析类的查询,后跟开发部确认。
他们自己认为是以下查询 有问题。
这里不太常用到的是: item:{$push:"
ROOT"}
这个功能是这样的: 查询 到的数据,把所有的数据明细表用$push 方式到item 再返回,
这样处理好处是在一个页面中,前面有汇总数据,后面还有对应的明细。
但缺点是如果明细值太大,那么就触发了上面的BUG.在官方BUG说明中是说在版本2.4.6就已解决了。但在2.6.8我们还
是遇到,也有可能很少这样用的原因吧。
db.getCollection('PInfo').aggregate([
{
$match:{MID:86}
},
{
$group : {
_id : { PID : "$PID"},
sumcount : { $sum : 1 },
item:{$push:"
ROOT"}
这个功能是这样的: 查询 到的数据,把所有的数据明细表用$push 方式到item 再返回,
这样处理好处是在一个页面中,前面有汇总数据,后面还有对应的明细。
但缺点是如果明细值太大,那么就触发了上面的BUG.在官方BUG说明中是说在版本2.4.6就已解决了。但在2.6.8我们还
是遇到,也有可能很少这样用的原因吧。
db.getCollection('PInfo').aggregate([
{
$match:{MID:86}
},
{
$group : {
_id : { PID : "$PID"},
sumcount : { $sum : 1 },
item:{$push:"
}
}
])
我们的解决方法:
把item 中$push 的值从总条记录,修改到只返回某几个字段(尽量少,同时不要返回子文档及数组,因为这两种类型很难预见有多大)
再把查询条件优化成最小,每次只查询少量数据。从而减少返回的数据量。