Двоичный журнал MySQL активирован = чертовски медленный высокопроизводительный сервер

В MySQL 5.1 (.57-1.dotdeb) у меня есть база данных ~ 2,0 ГБ и в среднем ~ 350 запросов в секунду.

Все работает нормально, если я не активирую двоичный журнал. Использование ЦП приличное (~ 15% от 1 ядра ЦП).

И если я активирую двоичный журнал, все внезапно становится ГИПЕРМедленным. Среднее количество запросов составляет ~ 90 запросов в секунду, и каждый запрос занимает +/- 4 секунды.

Вы должны знать, что:

• MySQL настроен правильно, tuning-primer.sh дает хорошие результаты в «нормальное» время
• Аппаратное обеспечение - Bi-Xeon E5620 (поколение Westmere) с 24 GO RAM.
• 12 ГО ОЗУ разрешено для InnoDB
• Запуск Debian 6 64 бит

Когда бинарный журнал активирован:

• Использование процессора MySQL чертовски НИЗКОЕ. Примерно 1 или 2% от 1 ядра. Не особо много% wa для ввода / вывода в "верхних", около 5-7%.
• Использование памяти кажется хорошо. Я тестировал с 1 GO для InnoDB вместо 12 GO, без изменений.
• Запросы так долго выполняются, что 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 @ Джейсон:

После установки innodb_log_file_size = 1G, выключив сервер, переименовал ib_logfile0 и ib_logfile1, перезапустил сервер с помощью binlog.

Сервер mysql просто вообще не отвечает. Он настолько медленный, что на этот раз страница не отображается.

Обратите внимание, что проблем не возникнет, если я снова отключу бинлог.

Средняя нагрузка кажется высокой: 3,5даже если процессор не так востребован ...

РЕДАКТИРОВАТЬ 3:

@ Джейсон, @ Брайан

После всего,

Похоже, это ошибка MySQL 5.1.

После многих тестов ничего не изменилось.

Не проблема, связанная с ЦП, ОЗУ или вводом-выводом.

Я переключил один из своих серверов на Percona MySQL 5.5, и теперь он отлично работает с тем же оборудованием, базой данных и конфигурацией.

Может быть, на 20% или 30% быстрее, чем MySQL 5.1 ...

Что еще?