feisuzhu

关于 LeanCloud 我就说一句：你应该找不到一家工单做的比 LeanCloud 更好的云服务了，LeanCloud 的工单都是直接发到相应服务负责人那里去的，不是只会回复车轱辘话的人员，而且很快。

利益相关：每天需要回工单的运维人员……

囧…… 能说一下工单号么

1. 不暴力，这样挺好（对你的程序来讲），不会有什么压力。被请求的资源可能就蛋疼了。可以的话还是用 gevent.pool.Pool 吧，就是把 gevent.spawn 改成 pool.spawn ，剩下的活 gevent 都帮你干了。

2. 没明白。如果只是 gevent.spawn 的话，是不会有新线程的（除非底层的代码用了，而且你也没 monkey patch ）。
你说的是每个 task 都有自己的调用栈吧？这个是正常的。

@oubushixb 咩哈哈
@nigelvon 晚上人多。论坛上可以直接看到在线人数。

@phoenixlzx
“也”？
可以分享一下经验么？

@9hills
出现问题的并不是 mesos-slave 或者 dockerd 本身，而是一个奇怪的 lsof 进程，这个进程只在部署了 mesos-slave 和 docker 的机器上出现。而且并不是 mesos-slave 或者 dockerd 的子进程，并不接受 cgroups 的监管。

@9hills
我的理解是，docker 是用 cgroups 做资源限制的（直接划等号肯定是不合适）。
所以说“预先用 cgroups 限制”实际是没有必要的，因为 docker 会帮你做。

@9hills
我们没有使用 mesos 自己的 containerizer，全部都在 docker 上，没有你说的这个问题。

@9hills
这次事故的导火索其实就是 mesos 和 docker，也就是你建议的 cgroups。（当然不是事故的原因不是 cgroups……
我们刚刚进行了 mongo 的升级，时间规划都是精确到分钟的。都这样了，本以为对 mongo 启动恢复什么的有一定了解，然而还是踩了坑……
（真想把锅丢给 mongo

利益相关： LeanCloud 运维，目测要背锅 _(:з」∠)_