Помогите с настройкой MySQL-сервера (my.cnf)

Привет.

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

Итак, имеется сервак:

CPU: Intel® Xeon® E3-1245 Quadcore incl. Hyper-Threading Technology
RAM: 16 GB DDR3 RAM ECC
Hard disks: 2 x 3 TB SATA 6 Gb/s HDD 7200 rpm (Software-RAID 1) Enterprise class

Одна база, движок InnoDB, ~60 таблиц. Запросами на всесение изменений (insert/update/delete) можно пренебречь, т.к. их в сутки случается буквально пару тысяч. Вся нагрузка - это селекты. Простые, или джойнами по несколько таблиц.

Понимаю, что вопрос может показаться глупым или наивным (мол, сделайте мне зае##сь), но все же. Если вдруг у кого-то есть стойкое мнение исходя из перечисленнйо информации, какие опции следует обязательно проставить в my.cnf, то пожалуйста, поделитесь им.

Спасибо.

 

Для чего тебе MySQL? Какая будет нагрузка? Просто не зная нагрузки, я могу сказать только, что на компе с 16 гигами оперативки MySQL работать будет.

В смысле, то, что ты написал ( несколько тысяч, селекты, пара-тройка JOIN ) - это и на дефолтных покатит.

Но необходимо знать примерное количество клиентов. Это важно.

 

blacktelecom

Ну сайт же

Просмотры по минутам:


Но это - живые юзеры. Поисковые боты генерят в разы больше трафика. На одну страницу, грубо говоря, генерится 5-30 запросов.

 

если запросы главным образом на чтение то много тут трогать не надо
главным образом включить кеширование и сделать query_cache_size побольше.
увеличить размеры join_buffer_size, innodb_buffer_pool_size

остальное можа по дефолту.

 

loginrl_103

Это рекомендуют ставить 60-80% от всей памяти. Я поставил 12Gb.

Какой примерно порядок цифр?

 

join_buffer_size - зависит от размера таблиц, вообще буфер этот под join (собсно название). 64мб должно хватить. (но этот буфер выделяется под каждый поток, поэтому посчитай чтоб суммарный объём памяти который может выделиться не превосходит объём всей памяти системы, mysqltuner это делает автоматически).

query_cache_size не стоит ставить под сотню мегов (большой кеш имеет свои негативные стороны), у меня 32 и нормально.

 

loginrl_103
Ага, спасибо. Вот еще интересуют параметры thread_concurrency - в доках написано "попробуйте поставить 2 х число ядер". То есть я ставлю 16? Кстати, небольшой оффтоп: чем отличаются cores от threads? Вторых обычно х2 первых. (8 threads, 4 cores). И thread_cache_size - я так и не понял что это вообще такое Кеш потоков? Всмысле, размер тредпула штоле?

 

>thread_concurrency
у себя не трогал, но увеличивать рекомендуется если нету много обращений к диску.

> thread_cache_size
> Всмысле, размер тредпула штоле?
да, чтоб тред не создавать он висит в кеше и когда нужен новый коннект, тред не создаётся, а берётся из кеша.

> чем отличаются cores от threads?
эмм а в каком контексте?

кстати игры с тредами не главный момент для оптимизации mysql.
Вообще тормоза сейчас наблюдаются?

 

loginrl_103

http://ark.intel.com/products/52274/Intel-Xeon-Processor-E3-1245-(8M-Cache-3_30-GHz)
# of Cores 4
# of Threads 8

Визуально из-за базы сайт не тормозит. ~100к просмотров в сутки, плюс еще N раз по столько же за счет поисковых ботов. Хочется понять, какой еще есть запас на этом сервере.

 

hyper threading же, виртуальные ядра

 

без знания специфики запросов сложно так спрогнозировать; нагрузочное тестирование, maatkit для начала для сбора статистики. потом можно jmeter'ом добивать.

 

Я более чем уверен, что все твои cores стоят без дела, а вся нагрузка идёт на винт. Посмотри iostat и сравни с максимальным. Если там уже всё по iostat забивается, то поможет только добавление новых винтов.
А 100к просмотров в день - это ерунда, так, детские шалости.

 

А, да, по возможности размести логфайлы InnoDB на одном винте, а файлы данных - на другом. Насколько помню, это затюнить в mysql можно.

 

SadKo
Думаю что винты не напрягаются - база вроде бы меньше, чем память выделенная под мускуль. О чем говорят эти адские цифры?

Код (Text):

1. avg-cpu:  %user   %nice %system %iowait  %steal   %idle
2.           13.39    0.00    0.85    0.39    0.00   85.37
3.  
4. Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
5. sdb              30.07        10.29       657.01    1997550  127581144
6. sda              30.21        10.82       657.01    2101528  127581144
7. md1               0.00         0.01         0.00       1408         12
8. md3               0.00         0.01         0.00       2346        464
9. md2              82.72        21.06       654.47    4089122  127087616

Такой возможности нет, ибо RAID-1

 

SadKo
Вообще я сейчас не представляю какая суммарная нагрузка на сервер - попробую скачать логи и посмотреть сколько делается запросов в том числе с поисковыми ботами.

 

cpu у тебя скучают, делать им нечего.
iostat надо смотреть так:

Код (Text):

1. iostat -cdk 5

Будет видно, kB_read/s и kB_wrtn/s.
Попробуй какой-нибудь жирный файлец покопировать с одного раздела на другой, сможешь замерить пиковые показатели и сравнить с нормальными.

 

SadKo
Хы, отпарсил логи Вчера было 434`000 запросов на страницы, которые дергают базу (5-30 запросов на страницу). Всего же на апач пришло 2`350`000 запросов (то есть включая картинки, стили, скрипты, и т.д.). При этом апач жмет все кроме картинок в gzip.

 

SadKo
kB_read/s почти всегда по нулям. Похоже что в 16 гигов оперативы влезла и вся база, и вся fs.

 

Ну тогда неплохо.
А так - всё равно нагрузка слабенькая.

 

SadKo
Вот еще ламерский вопрос Процент загрузки CPU, которые показывают top и htop, это что? Сумма процентов по ядрам? Процент от всего CPU? Или что? top иногда показывает больше 100%.