1
heimonsy 2017-01-10 18:11:45 +08:00
上代码
|
2
sujin190 OP |
4
heimonsy 2017-01-10 19:48:49 +08:00
我测试没有任何问题
|
7
zjx20 2017-01-10 20:00:58 +08:00
更新 1 :
加了-race 参数就能顺利跑完 go run -race test_mgo.go 更新 2 : 60 秒应该是 socket 超时,设置 session.SetSocketTimeout(35*time.Second) ,就会变成每 35 秒输出一条 感觉确实是 mgo 的问题,建议楼主去 github 提 issue |
8
heimonsy 2017-01-10 20:07:47 +08:00
这个应该跟用的 mongodb 的配置有关,我这边反正一点问题都没有,顺利跑完, mongodb 是 ubuntu apt-get 装的 v2.6.10
|
9
janxin 2017-01-10 22:47:35 +08:00
ulimit -a 看看改过没有?
|
12
mengskysama 2017-01-11 02:06:36 +08:00 1
可能是 setMode 造成的,只有 Monotonic 是 session 线程安全的,对没个 go 你试试用 session.Clone() Close()方法试试?
|
13
struCoder 2017-01-11 14:24:40 +08:00
直接
for(){go foo()} 效率还是很低的,一方面是系统资源的申请还有 fd 的限制 第二就是资源回收。 建议用 chan 做队列和配合 select 效果应该很好 |
14
fuxiaohei 2017-01-11 14:26:33 +08:00 1
不要一直用一个 *mgo.Session ,尽量 Clone 新的 来用
|
17
sujin190 OP @fuxiaohei 那么这样岂不要不断的关闭连接打开新连接了,如果有副本集的话,还有不断更新集群信息,这样效率太低了吧
|
20
zjx20 2017-01-11 15:01:31 +08:00
昨晚试过在 for 循环里面 clone ,然后在 test()里面调 close ,结果还是不行
for i := 0; i < 100001; i++ { go test(session.Clone(), i) } 刚刚又试了一下把 clone 也放到 test()里面,就顺利跑完了。 看来 clone 需要在使用的 goroutine 里面调才有效 |
21
njutree 2017-01-11 16:14:01 +08:00
根据我的理解这个不是死锁,是卡住了。 mgo.Session 会起一个协程运行 readLoop() 读取数据,这里面会有很多锁,也就是当你开的协程少(具体看机器配置)时是没有什么问题的。 一旦你把协程数提高比如你代码里面的 10w 时, readLoop() 协程能分配到的计算资源有限,所以就会出现卡住或缓慢得到查询请求的情况。 你可以把协程数降低,单个协程的查询数提高,查询速度就会变快。 同理 copy 多个 mgo.Session 就会有启多个 readLoop() 协程 ,每个查询在对应的 readLoop ,执行回调就不会卡住了。
|
22
sujin190 OP |