@onlineismy 其实我知道这个过程，只是数据量和 fork 时间影响比我想象的大多了，所以是不是还有其他的坑呢

@500miles 内存只用了四分之一，应该不是这个问题

@500miles 这个系统调用不是同步文件写到磁盘的么？主进程还会有这个调用？

@tczzjin 现在就是这么干的，还不错

@SErHo 可是在 bgsave 过程中，响应延时都过秒了，也和那不一样啊，奇怪

@killpanda 不可能吧

@czheo 8 核，就跑了一个 redis 实例

@SlipStupig dict 对象不是还要占内存么？你删除了 dict 对象内存当然会释放一部分了

整数缓存，每个整个只分配一次内存，但一旦分配了内存一般是不回收的，即使不使用了

这个明显得看你启动 DBUtils 的时机了吧，是在 fork 之前还是之后， fork 之后创建的连接肯定只能在本进程用啊，不过话说 python work 一般都是单线程的， DBUtils 没什么用处吧，开个连接一直挂着就是了，使用时检测下是否还正常就是了，完全不需要那么复杂的连接池管理机制

@LeoXu 有什么问题么？其实很久不写博客了。。

@csdreamdong 你可以 telnet 连一下端口看看

uwsgi 中又请求了其他网站的接口？或是访问了其他机器的数据库之类的

你应该用 tornado 的 AsyncClient ，并且好像 AsyncClient 是可以下载一部分来个回调你发给客户端就行，如果还不行，你直接用 IOStream 连也可以啊， IOStream 每下载一部分就会回调

@zhu327 没有连接池的话性能起不来吧，连接池还要负责排队，阻塞清除之类的，否则异步很容易挂的
对，原来的 IOStream 是为了各种情况读写而设计的，太慢了， mysql 协议读写过程很稳定，不需要那么复杂的读写过程，重写之后 cpython 快了近 40%， pypy 上快了 3 倍。。

@zhu327 好想法，不过 django 是线程安全的么？没注意他文档中怎么写的，包括内部的连接池之类的，如果异步 mysql 没有连接池支持的话会性能更低吧，我只看过早先版本的 django 连接池实现，好像不能支持这种情况吧

其实想 tornado 想这样异步使用 mysql 虽说可以，但真要想用在生产环境，还是要做很多要调整的，异步使用 mysql 和同步有很多不一样的地方
https://github.com/snower/TorMySQL
我实现的，已用在生产环境中，数百并发，每天千万流量下稳定运行。

如果只是纯接口，不渲染模板的话，其实完全没有必要使用 ORM ， model 什么的话，只是分层问题而已，你只要方便控制扩展，怎么着都行，如果不是纯接口的话， tornado 太费力了
tornado 做接口，而使用异步数据库驱动和不使用又各有好处，不断调试到适合你的事一个辛苦的过程。
整体来说可能还是使用异步驱动适应力更强一些。

@Infernalzero 没有这段啊。。不过有这个 INNODB MONITOR OUTPUT