MySQL - оптимизация быстродействия в my.cnf
В файле my.cnf (по умолчанию /etc/my.cnf) существует достаточно много настроек, которые влияют на быстродействие MySQL, при этом универсального рецепта нет. На серверах, где много оперативной памяти, можно попробовать уменьшить количество операций с жестким диском (которые будут выполняться дольше и потреблять больше ресурсов процессора) путем увеличения работы с RAM и так далее. В общем для разных конфигураций железа, будут разные конфигурации my.cnf, однако сама настройка my.cnf должна иметь общие принципы и зависимости. Правильная настройка требует концептуального понимания, процессов происходящих в MySQL, а эта информация не лежит на поверхности. Но все же оптимальные настройки прямо сейчас - так хочется! И я начал делать первые шаги в этом направлении…
Для начала, обнаружил замечательный perl скрипт mysqltuner.pl, скачать который можно на сайте www.mysqltuner.com Данный скрипт, при запуске анализирует текущее состояние MySQL и дает рекомендации по настройкам.Еще один скрипт tuning-primer.sh так же делает нечто подобное - анализирует большое количество параметров и логов, после чего дает рекомендации. Скачать скрипт можно
http://man-linux.ru/ext/aHR0cDovL3d3dy5kYXkzMi5jb20vTXlTUUwvdHVuaW5nLXByaW1lci5zaA==/
http://man-linux.ru/wp-content/plugins/wp-downloadMonitor/download.php?id=5 Данный скрипт так же очень хорошо помогает понять некоторые процессы и взаимосвязи и дает весьма полезные рекомендации. Использование двух этих скриптов позволяет выполнить аудит текущих настроек MySQL и привести их к более оптимальному виду, за несколько минут.
Upd: Рекомендации - рекомендациями, однако все равно, необходимо понимать, что делаешь и взаимосвязи действий и последствий. Например, параметр table_cache Скрипт tuning-primer.sh показывает процент использования данного кеша, например разрешено 100 таблиц, открыто 100 таблиц, таким образом кеш использован на 100%, а далее рекомендация гласит “вероятно вам стоит увеличить table_cache”. Здесь есть один нюанс, о котором не сказано в скрипте - table_cache влияет на общее количество файлов, которые могут быть mysql и как следствие на общее количество файлов, которые в какой-то момент смогут быть открытыми в операционной системе. Однако же есть общее ограничение в ОС, и слишком большое значение tablce_cache может привести к тому, что будут использованы все доступные файловые дескрипторы. Команда:
sysctl fs.file-max
Покаже максимальное количество файлов, которые могут быть открыты в ОС. Поменять это значение можно например так:
sysctl -w fs.file-max=399086
Посмотреть же, сколько файлов открыто в системе в текущий момент можно командой:
lsof | wc -l
Это позволит сориентироваться в том, какое значение table_cache допустимо.
Настройка MySQL my.cnf
Долго я ковырял настройки MySQL
Вот, приблизительный конфиг для для 2Гб VPS/VDS (2-х ядерного)
Надо сказать, что вариант эксперементальный, но вполне рабочий, допускает корректировки, где-то можно подрезать буфер или наоборот накинуть немного.
Замечу, что на каждом сервере должен быть свой конфиг для конкретных задач (сайтов) я предполагаю среднюю посещаемость сайта без серьезной нагрузки (для высоконагруженных проектов не следует использовать VPS с 2Гб памяти, есть DS на многоядерных Xenon с 64Гб RAM)
Итак, содержимое /etc/mysql/my.cnf
key_buffer_size = 256M # размер буфера, используемого для блоков индексов (рекомендуется 25% от ОЗУ) является общим для всех потоков max_allowed_packet = 16M # max_connections = 50 # 50 — это мало для высоконагруженных проектов(как и VPS для таких проектов — это недостаточно) даже в данном случае можно смело повысит до 70, если поставить 100 — съест более 90% памяти, а у нас еще там апач стоит с java и прочие радости для сервера или же уменьшаем(постути жертвуем) выделение памяти под буферы и ставим max_connections сколько требуется thread_cache_size = 51 # число открытых потоков в кэше для обслуживания новых соединений (лучше больше) table_open_cache = 634 # Количество открытых таблиц для всех потоков (зависит от кол-во таблиц, лучше ставить больше) tmp_table_size = 128M # максимальный размер памяти для временных таблиц (устанавливается эксперементальным путём, желательно выше 32М) max_heap_table_size = 128M # максимальный допустимый размер временной таблицы (устанавливается эксперементальным путём, желательно выше 32М) thread_concurrency = 4 # количество одновременных процессов, обрабатывающих конкурентные запросы к mysql. Рекомендуется установить значение, равное количеству процессов или ядер сервера, умноженное на два. join_buffer_size = 2M # индивидуальный параметр, вполне может хватить и 1М или меньше open_files_limit = 2048 # лучше больше innodb_buffer_pool_size = 400M # зависит скорее от необходимости, надо мониторить и ставить больше чем потребляется по факту wait_timeout = 30 # сколько времени сервер ждет в секундах прежде чем закрыть соединение interactive_timeout = 60 sort_buffer_size = 4M # поток, которому необходимо произвести сортировку, выделяет буфер данного размера (можно больше с оглядкой на расход памяти) read_buffer_size = 1M # рекомендуется в 4-е раза больше, чем sort_buffer_size query_cache_limit = 8M # по умолчанию – 1Мб, результаты, превышающие это значение, не кэшируются, слишком большое значение смысла не имеет query_cache_size = 128M # сколько памяти выделить для внутреннего кэша запросов mysql, вычисляется опытным путем, по фактическому потреблению, но опять же мы ограничены 2Гб в данном конкретном случае (рекомендуется указывать 20% — 10% от ОЗУ)