☰

MySQL 二进制日志激活 = 高端服务器速度太慢

tag-icon • tag-icon mysql performance logging replication binary
MySQL 二进制日志激活 = 高端服务器速度太慢

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

如果我不激活二进制日志，一切都会运行良好。CPU 使用率还不错（约 1 个 CPU 核心的 15%）。

如果我激活二进制日志，一切都会突然变得超级慢。请求平均下降到每秒约 90 个请求，每个请求需要 +/- 4 秒才能完成。

你必须知道：

  • MySQL 经过适当调整，tuning-primer.sh 在“正常”时间内给出了良好的结果
  • 硬件是 Bi-Xeon E5620（Westmere 代），配备 24 GO RAM
  • InnoDB 允许使用 12 GB 的 RAM
  • 运行 Debian 6 64 位

当二进制日志被激活时：

  • MySQL 的 CPU 使用率非常低。大约占 1 个核心的 1% 或 2%。“top”中 I/O 的 %wa 不多，大约为 5-7%。
  • 内存使用情况似乎很好。我已经用 1 GO 而不是 12 GO 对 InnoDB 进行了测试，没有变化。
  • 查询执行时间太长，因此 php5-fpm 创建了许多新进程来处理流量。

在正常时间，我有大约 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，关闭服务器，重命名ib_logfile0和ib_logfile1，用binlog重新启动服务器。

mysql 服务器完全没有响应。速度太慢了，这次没有显示任何页面。

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

平均负载似乎很高：3.5，即使 CPU 没有如此请求......

编辑3：

@Jason、@Bryan

毕竟，

这似乎是 MySQL 5.1 的一个 bug。

经过多次测试，什么都没有改变。

这不是与 CPU、RAM 或 IO 相关的问题。

我将我的一台服务器切换到 Percona MySQL 5.5，现在它可以正常工作，使用相同的硬件、数据库和配置。

可能比 MySQL 5.1 快 20％ 或 30％......

还有什么？

答案1

您的读写分布是怎样的？您有写入密集型应用程序吗？

你的磁盘子系统是什么样的？

您没有指定 innodb_log_file_size。在繁忙的服务器上，默认值太低了。启用二进制日志后，增加该值可能会帮助解决 I/O 问题。

此外，不建议使用 sync_binlog = 0，因为如果服务器崩溃，您的二进制日志将与事务不同步。

干杯

答案2

您的硬件设置在内存和处理器方面似乎非常强大。打开 bin-logs 意味着要向磁盘写入更多内容，您是否尝试过将 bin-logs 放在不同的物理磁盘上？

相关内容