MySQL二进制日志激活=高端服务器该死的慢

在MySQL 5.1（.57-1.dotdeb）上，我有一个〜2.0Gb的数据库，平均每秒约350个请求。

如果我不激活二进制日志，所有运行正常。 CPU使用率不错（〜1 CPU内核的15％）。

如果我激活二进制日志，所有突然HYPER慢。 请求平均下降到约90个请求/秒，每个请求需要+/- 4秒才能完成。

你必须知道：

• Mongo不使用二级读取副本/分片mongo设置
• pg_basebackup：无法从服务器获取WAL结束位置
• 跨WAN的DFS复制
• MySQL多级复制不断中断
• 为什么复制失败，错误重复input密钥？

• MySQL正确调整，tuning-primer.sh在“正常”时间内给出好的结果
• 硬件是Bi-Xeon E5620（Westmere世代），带有24个GO RAM
• InnoDB允许12个RAM的GO
• 运行Debian 6 64bits

当二进制日志被激活时：

• MySQL的CPU使用率很低。 约1或2％的1核心。 “顶”的I / O没有太多的百分之五，约5-7％。
• 内存使用看起来不错。 我已经testing了1个GO，而不是12个GO，没有改变。
• 查询是很长的执行，然后php5-fpm创build了很多新的进程来处理stream量。

在正常情况下，我有大约15位PHP-FPM工作者，如果二进制日志被激活，这个数字可以达到150-200（最大值）。

没有必要确定所有的系统在这个时候都被冻结了。 🙂

这是my.cnf：

  [client] port = 3306 socket = /var/run/mysqld/mysqld.sock [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp language = /usr/share/mysql/english skip-external-locking bind-address = 127.0.0.1 key_buffer = 16M max_allowed_packet = 16M thread_stack = 192K thread_cache_size = 32 myisam-recover = BACKUP max_connections = 200 table_cache = 512 #thread_concurrency = 10 query_cache_limit = 1M query_cache_size = 16M max_heap_table_size = 64M tmp_table_size = 64M innodb_buffer_pool_size = 12G #general_log_file = /var/log/mysql/mysql.log #general_log = 1 long_query_time = 4 #log_slow_queries = /var/log/mysql/mysql-slow.log #log-queries-not-using-indexes #server-id = 1 #report-host=host # NOTE : All the values here are uncommented when i activate binlog #log-bin = /var/log/mysql/mysql-bin.log #log-error = /var/log/mysql/mysql-err.log #sync_binlog = 0 #binlog_cache_size = 128M #expire_logs_days = 2 #max_binlog_size = 100M #max_binlog_cache_size = 1G [mysqldump] quick quote-names max_allowed_packet = 16M [mysql] #no-auto-rehash # faster start of mysql but no tab completition [isamchk] key_buffer = 16M !includedir /etc/mysql/conf.d/ 

告诉我，如果你有任何关于这个问题的想法！

谢谢

---

编辑1 @Jason：

设置innodb_log_file_size = 1G ，closures服务器，重命名ib_logfile0和ib_logfile1，用binlog重新启动服务器。

MySQL服务器根本就没有响应。 这是如此之慢，这个时候没有页面显示。

请注意，如果我再次停用binlog，则不会有任何问题。

负载平均值似乎很高：3.5 ，即使CPU没有被请求…

---

编辑3：

@Jason，@Bryan

毕竟，

这似乎是MySQL 5.1的一个错误。

经过多次testing，没有任何改变。

不是CPU，RAM或IO相关的问题。

我将我的服务器之一切换到Percona MySQL 5.5，它现在正常工作，具有相同的硬件，数据库和configuration。

也许比MySQL 5.1快20％或30％…

还有什么？