监控一下数据库的 io 是不是瓶颈，特别是 io wait 值。

还有可能是 mysql 的 query cache 设置不正确导致 commit 的时候，需要清理过多的 query cache。 show variables like 'query_cache%'; show global status like 'Qc%';

transaction 本来就是比较慢的。

http://railscasts.com/episodes/368-miniprofiler

#1 楼 @quakewang 我的 query_cache 只有 16M，应该 ok 吧。

我监控一下 io。。。

#2 楼 @rasefon 随机发生的，不是每个 commit 都慢

那个 commit 做了啥，在哪些点数据库压力如何，有多少同步的操作。

#1 楼 @quakewang 话说，你用什么监控 io 啊？看了一下 scoutapp 才 3 分钟的解析度貌似不够啊。。。

#6 楼 @yedingding INSERT 也会出现 >2000ms 的状况，比如 newrelic 记录了这个画了 ~2700ms。

INSERT INTO orders (account_id, address1, book_id, created_at, final_amount, notes, paid_at, partner_id, payment_method, phone, quantity, receiver_name, region1, region2, region3, shipping_no, state, taobao_account, token, type, updated_at) VALUES (?, NULL, NULL, ?, NULL, NULL, NULL, NULL, ?, NULL, ?, NULL, NULL, NULL, NULL, NULL, ?, NULL, ?, ?,?,?)

应该和 query 本身没太大关系。

是不是在 callback 里做了有外部请求的操作？比如发邮件、请求 API 之类。如果有，可以在 after_commit 后调用..

#9 楼 @hooopo 是 sql query 本身花了 >2000ms，不是请求

#7 楼 @hayeah 命令行 iostat 3

#8 楼 @hayeah 嗯，要看当时数据库的情况，这个数据库哪些应用在用？数据量多少，索引设计是不是合理，有没有竞态的发生等等。用 vmstat/iostat 看系统的情况，也可以看看 mysql 进程的 smaps

@quakewang 我们现在也部署在 ucloud 上。你知道 disk io 的瓶颈大概在哪里吗？我看了一些实时数据，有时候 mysql 写入会持续两三秒，达到每秒精度接近 2000kB 峰值

我猜很有可能是硬盘满了，或者有坏道

如果业务上没有规律，感觉可能压力，top 看一下发生的时候的压力大不大，如果很小，可能是配置，比如连接数，操作并发数什么的，mysql 不知道有没有，postgresql 是有的

还有就是可能是应用设置的连接数