Прежде чем такое воротить с конфигом, нужно понимать что делаете.

сейчас

(64k+256k+128M) * кол-во потоков + 128M key_buffer_size = писец

Не уверен что вам нужно max_allowed_packet = 128M, но попробуйте так:

Код:

Код:

Сейчас имею следующие настройки
и имею 504 Gateway Time-out

На одном из моих серверов с выше приведенным конфигом крутится ДЛЕ с базой 200мб, посещаемость ~350k уников в месяц, АМД 5000+/2гб озу, чистый апач2, без нгинкса... Пиковая загрузка от мускула в топе до 20%, хотелось бы меньше, но пока и так нормально.

Поясниловка.

Кеширование запросов это важно

query-cache-type = 1 (1 – это ДА) query_cache_size = ??????М

Настройки кэширования запросов позволяют ускорить работу MySQL за счет того, что если MySQL получает одинаковые запросы, то тогда ответы на эти запросы могут быть возвращены из кэша.

Буфера(Ы)

low-priority-updates

set-variable= key_buffer_size=???M

set-variable= join_buffer_size=???kb

read_buffer.size = ???k

sort_buffer_size = ???k

read_rnd_buffer_size= ?m

Если у вас происходят преимущественно выборки из таблицы, то можно включить опцию low-priority-updates - это повысит приоритет SELECT запросов по сравнению с UPDATE/INSERT.

Параметр key_buffer_size определяет размер памяти, который будет отведен под кэширование индексов таблиц. Это общий кэш для всех соединений. Под этот кэш обычно выделяют до 25-30% всей оперативки.

Параметр join_buffer_size указывает размер буфера, используемого при SELECT FROM a JOIN b запросах, в которых происходит JOIN двух таблиц. Этот буфер используется только если НЕ могут быть использованы индексы таблиц. Если же на таблицах есть индексы и они могут использоваться для JOIN-a, то тогда этот параметр бесполезен и лишний.

Если делается много последовательных чтений из таблицы, то нужно увеличить параметр read_buffer_size, который указывает сколько памяти выделать каждому потоку для последовательного сканирования таблицы. Это размер памяти для каждого потока, т.е в максимуме может потребить read_buffer_size * max_connections.

Если делаются запросы, результат которых должен быть отсортирован и на таблице есть индексы, то для улучшения производительности можно увеличить read_rnd_buffer_size. Это улучшит производительность запросов с ORDER BY. Это параметр задает размер памяти для каждого потока.

Любой запрос, который выполняет операции сортировки ORDER BY и группировки GROUP BY, предварительно выделяет буфер размером sort _buffer_size. Увеличение этого параметра улучшает производительность запросов ORDER BY и GROUP BY. Это параметр задает размер для каждого потока.

Итожим:

Для каждого потока клиента будет выделяться

join_buffer_size + read_buffer_size + read_rnd_buffer_size + sort_buffer_size

А в общем MySQL поглотит

(join_buffer_size + read_buffer_size + sort_buffer_size + read_rnd_buffer_size ) * max_connections + key_buffer_size = ?????????????

Циферки подставьте сами, и начните читать man-ы, а не тупо лепить что побольше.

Чтобы задать оптимальные настройки, мало знать сколько оперативки можно запихать под MySQL, нужно еще залесть в скрипты и посмотреть что там творится и с какой периодичностью.