Оптимизация mysqld под большие (huge) нагрузки

[kvn]

Оптимизация mysqld под большие (huge) нагрузки

Привет.

Присоветуйте, пожалуйста дельные статьи по оптимизации mysqld для очень больших нагрузок (желательно под FreeBSD).
По правильному выделению памяти на процессы, на кеши, буфферы и т.п., при условии, что машинка на которой это все вертиться примерно такая xeon 2x3G CPU/ 4G RAM/SCSI и т.п.

стоит max_connections = 700, но реально при тесте ~260-300 одновременных коннектов база уходит в ступор, и отваливает всех остальных по Can't connect to socket /tmp/mysql.sock...

Может есть какие-то доки потолковей чем mysql manual? Т.к. в мануалке как-то все абстрактно написано, да еще и из расчета на 64M RAM, и непонятно на какие тазики...

Заранее благодарен.

 

[Steamroller]

В дистрибутиве есть примеры конфигов, можно сделать что-то на основе /usr/local/share/mysql/my-huge.cnf.
Доков по именно настройке параметров толковых нету. Только мануал и их списки рассылки. По оптимизации вообще есть еще книжка Zawodny, и статьи всякие.

 

[si]

на счет непосредственно цифр они есть в дистрибутиве в my-huge.cnf (или как-то похоже он называется). одно замечание из опыта про key_buffers, когда мы его ставили очень большим скажем 700M против обычных 384M, то через какое-то время работы mysql начинал тормозить, помогал только рестарт mysqld.
было год назад примерно возможно это уже по правили, либо вплне может что не хватало ОС памяти под дисковый кеш (тогда на машинах было всего 2G)

на счет FreeBSD имхо это не самый лучший выбор для этой задачи. в инете полно сообщений о порче таблиц именно в такой конфигурации FreeBSD+mysql
с большой нагрузкой.

еще имеет смысл попытаться ограничить колво конектов, по моим ощущения после 300 начинаются тормоза. для этого можно применить обычную схему
с frontend-backend. с клиентов общается frontend, запрос позывалая на backend, после чего frontend получается себе весь ответ и начинает его
медленно и печально отдавать клиенту. при этот backend процесс уже может обрабатывать следующие запросы.

ну и стандартно master -> multi slave если один mysql уже не тянет.

 

[kvn]

когда мы его ставили очень большим скажем 700M против обычных 384M, то через какое-то время работы mysql начинал тормозить, помогал только рестарт mysqld.

Это никак не удалось полечить?

 

[si]

в тот момент оставили его в районе 384M.

сейчас в сервера добавили памяти до 8G, после этого по графикам io wait значительно упала (в разы), настройки mysql при этом не меняли.

 

[Anton_D]

Вот достаточно дельные статейки по оптимизации MySql:
http://www.databasejournal.com/features/mysql/article.php/3367871

Если совсем вкратце, то в key_buffer_size должны влезать все индексы, но кажется не более трети общего объема RAM.

max_connections = по необходимости, я ставлю примероно 1.5 от Max_used_connections при большом аптайме. Больше все равно бессмысленно.

table_cache - сколько памяти хватит.
В статейке есть примеры простейшей диагностики.

kvn
Только не пойму, max_connections = 700 - зачем столько?
Неужели столько реально бывает? Для такого количества коннектов нужно не 4 а 40 гб мозгов, и то мало будет, если база хотябы гигабайт-другой весит. Threads_connected и Threads_running сколько обычно показывают? А случаем приложение не persistent коннектом к базе цепляется? Файлдескрипторов хватает? Mysql 'Too many open files' не ругается?

 

[Steamroller]

Если совсем вкратце, то в key_buffer_size должны влезать все индексы, но кажется не более трети общего объема RAM.

Если они влезают, значит база слишком маленькая.

table_cache - сколько памяти хватит.

Очень и очень спорная штука. Оверхед на открытии/закрытии таблиц - мизерный, а вот разрушение индексов получить, держа все таблицы открытыми всегда - легко можно.

 

[ForJest]

Steamroller
Это не спорная штука. Это реальность - если стоит max_connections = 700 и table_cache=64 то будут серьёзные проблемы.
Я могу ошибаться, но по-моему если таблица закрыта, не открыта то запрос будет Locked, в любом случае - и при запросе на select и на update.
Отсюда получаем лишние блокировки процессов, лишнюю нагрузку, херово короче всё начинает работать.
Так что table_cache, из практики - это очень важное значение.

 

[Steamroller]

ForJest, видимо ты что-то путаешь. table_cache никак не ограничивает число открытых таблиц, и не влияет на блокировку этих таблиц.
Проблемы же при реальном числе одновременных активных подключений 700 - будут всегда, просто MySQL на такие подвиги не способен.

 

[Anton_D]

Steamroller

Проблемы же при реальном числе одновременных активных подключений 700 - будут всегда, просто MySQL на такие подвиги не способен.

Категорически согласен.

kvn
А поэтому вот интересно, что это за приложение такое, способное так нагрузить сервер? Или это просто такой некорректный тест? Какой смысл тестить сервер на такое количество соединений?