Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
В общем ситуевина такая..
Есть MySQL версии 5.1.49 работающий под управленем Debian GNU/Linux версии 6.0.2. Который в свою очередь вогружен на DELL R710 с 6х300G SAS 15K RAID 6 CPU x2 E5506 2.13GHz и 32GB памяти.
Размер базы 256Gb, таблицы в основном InnoDB, есть и MyISAM но мало. Приложение которое работает с базой закрытое и модифицировать запросы мы не можем.
Нагрузка на базу в среднем 9000 запросов в минуту, в пике (который длится около часа-двух) 147000 запросов в минуту.
Рейтинг запросов примерно выглядит так SELECT 30%, UPDATE 40%, INSERT 30%.
В кеш запросов попадает где-то 20% запросов, я так понимаю из=за большого количества запросов содержащие многоэтажные JOINы.
Собственно, что происходит.. На момент запуска базы и приложения, все ок, но спустя пару суток база начинает жутко тупить на UPDATE и INSERT.
Ниже конфиг.. сразу говорю я не DBA, настраивал эмпирически + google.
Неактивен
Странные параметры следующие:
table_cache = 3G
Это значение должно быть целым числом (число таблиц). 3 миллиарда - неадекватное значение.
net_buffer_length = 100M
sort_buffer_size = 912M
join_buffer_size = 1G
Эти параметры выделяются на соединение. То есть каждый коннект может съесть 1 гиг на джойн и почти гиг на сорт. Это недопустимо при вашей одновременность.
key_buffer_size = 8G
посмотрите заполнен ли он SHOW GLOBAL STATUS LIKE 'key_blocks%';
max_allowed_packet = 800M
open_files_limit = 100000
read_buffer_size = 280M
read_rnd_buffer_size = 460M
binlog_format = row
sync_binlog = 1
max_write_lock_count = 1
#transaction-isolation = READ-COMMITTED
max_length_for_sort_data = 1G
bulk_insert_buffer_size = 456M
myisam_sort_buffer_size = 712M
myisam_max_sort_file_size = 2G
С этими параметрами тоже непонятно - зачем они?
Неактивен
Странные параметры следующие:
table_cache = 3G
Это значение должно быть целым числом (число таблиц). 3 миллиарда - неадекватное значение.
Согласен не верно понял доку, тем не менее сервер баз данных сам снижает эти значения
Типа : [Warning] option 'table_cache': unsigned value 3221225472 adjusted to 524288
net_buffer_length = 100M
sort_buffer_size = 912M
join_buffer_size = 1G
Эти параметры выделяются на соединение. То есть каждый коннект может съесть 1 гиг на джойн и почти гиг на сорт. Это недопустимо при вашей одновременность.
Да, в поле.. Повышал значения опции по мере появления соответствующих предупреждений от сервака.
Косяк в том что само приложение делаем запросы с большим количеством JOIN + многи затронутые таблицы содержат TEXT и BLOB поля, отсюда вытекает необходимость прочих настроек.
ЗЫ
Опция #transaction-isolation = READ-COMMITTED за время своей активности превратила данные в кашу..
По вашим замечаниям вроде все поправил, буду ждать момента дабы перезагрузить сервер и проверить..
Неактивен
Valor написал:
Типа : [Warning] option 'table_cache': unsigned value 3221225472 adjusted to 524288
540 тысяч все равно много?
Valor написал:
Да, в поле.. Повышал значения опции по мере появления соответствующих предупреждений от сервака.
Как он об этом сообщал?
Valor написал:
Косяк в том что само приложение делаем запросы с большим количеством JOIN + многи затронутые таблицы содержат TEXT и BLOB поля, отсюда вытекает необходимость прочих настроек.
Хотя вы и писали, что приложение исправить нельзя, не могу не отметить, что если в JOIN и ORDER BY участвуют TEXT и BLOB, то при том количестве запросов, которое вы указали сервер гарантировано залочится. В идеале нужно переписывать все запросы так, чтобы блобы не участвовали в сортировке, а выбирались потом. В вашем случае может помочь анализ медленных запросов и создание индексов для них.
Неактивен
Хотя вы и писали, что приложение исправить нельзя, не могу не отметить, что если в JOIN и ORDER BY участвуют TEXT и BLOB, то при том количестве запросов, которое вы указали сервер гарантировано залочится. В идеале нужно переписывать все запросы так, чтобы блобы не участвовали в сортировке, а выбирались потом. В вашем случае может помочь анализ медленных запросов и создание индексов для них.
Спасибо, по ходу придется таки озадачится анализом медленных запросов.
Вот новая напасть..
120506 11:27:03 InnoDB: Warning: cannot find a free slot for an undo log. Do you have too InnoDB: many active transactions running concurrently?
Неактивен
У вас max_connections = 7000, но иннодб держит не более 1023 одновременных транзакций (см. здесь http://www.mysqlperformanceblog.com/200 … nonsenses/ ). Снизьте max_connections и одновременно посмотрите SHOW FULL PROCESSLIST, почему столько запросов одновременно выполняется.
Неактивен
Страниц: 1