My cnf где находится windows
Обновлено: 06.07.2024
Один из важных моментов в скорости работы сайта, это правильная оптимизация конфигурационного файла базы данных my.cnf, с которым многие сталкиваются в процессе оптимизации системных ресурсов. Зачастую многие приведенные в сети мануалы рассказывают о настройках которые были применены к слабым конфигурациям и это не дает нужного ответа.
Я обычно использую сервера на уровне ксеонов с 32 гигабайтами памяти, поэтому найти нужную конфигурацию настроек mysql достаточно трудно, отсюда и попытки настроить самому методом тыка и проб. Что из этого получилось сегодня я постараюсь рассказать.
Исходные данные для настройки
Итак рассматриваем систему с установленным ISP manager на котором стоит Centos и MariaDB. Задача, оптимизировать работу Mysql и ускорить тем самым обработку запросов на сайтах. Для начала я приведу, пример своего my.cnf который находится по адресу etc/my.cnf, если у вас стоит Debian то смотреть надо в папке другой. Итак вот так выглядит настроенный файл, но иногда я все таки еще изменяю некоторые настройки, о которых расскажу ниже.
Тюнинг базы данных Mysql варианты
Итак что я меняю и что вижу при этом. Для начала выведу основные параметры которые считаю спорными в настройке.
Разбор параметров тюнинга Mysql
Разберёмся по порядку с каждым параметром настройки и вопросами которые есть при этом. Итак по пунктам.
key_buffer = 2Gkey_buffer_size = 4G
Так и не смог я понять, различаются ли эти два параметра или первый является устаревшим значением второго.
max_connections = 500 и thread-cache-size = 500
По замерам выходило, что не более 90 одновременных подключений, так и поставил 500 с запасом. Тут следует учесть что следующий параметр thread-cache-size должен быть одинаковым числом с максимальным соединением. Поэтому там также стоит 500.
table-cache = 120000 и table-open-cache = 120000
Здесь я поставил по 120000, так как таблиц у меня достаточно много, если у вас не много сайтов, то этот параметр можно не повышать.
interactive-timeout = 360
Установил в 360, чтобы снимались запросы, которые находятся без активности 6 минут или 360 секунд.
query_cache_limit = 12Mquery_cache_size = 4Gjoin_buffer_size = 512M
Следующие три параметра настроил исходя из следующих наблюдений. Пробовал ставить query_cache_size от 2 до 6 гигабайт, в итоге оптимально показалось 4. Обработка запросов до 12 мегабайт мне вполне хватало, поэтому оставил 12. Но есть такое мнение, что большой query_cache_size на самом деле сильно грузит систему и желательно держать кеш в memcashed, на практике я не заметил особо, чтобы он забирал мощность, а вот при проверке кеша, обнаружил, что много запросов проходит через него.
sort_buffer_size = 1Gread_buffer_size = 1Gread_rnd_buffer_size = 2G
Буфера поставил побольше, так как несколько баз имеют большой размер, хотя есть риск переполнения памяти, тем не менее они настолько не забивали память.
Новые изменения настройки my.cnf в 2021 году
Времена идут, знания становятся лучше, поэтому я уже практически во многом перенастроил свои файлы конфигов базы данных. Сразу скажу, что в основном этот конфиг рассчитан по моим базам данных, это порядка 14 гигабайт данных на серверах с 32 памяти оперативной, ssd дисками и собственно выкручено все на соотношение скорость работы + стабильность. Поэтому вот такой конфиг сейчас использую на Centos 8 с указанными параметрами серверов.
Программа mysqld понимает параметры командной строки:
MySQL может, начиная с версии 3.22, читать заданные по умолчанию параметры запуска для клиентов и сервера из файлов опций.
MySQL читает заданные по умолчанию параметры из следующих файлов (в Unix):
/.my.cnf
DATADIR представляет собой каталог данных MySQL (обычно `/usr/local/mysql/data' для бинарного дистрибутива или `/usr/local/var' для установки из исходников). Обратите внимание, что это тот каталог, который был определен в конфигурации, а не указан в опции --datadir при запуске mysqld ! Параметр --datadir не имеет никакого эффекта в то время, когда сервер ищет файлы опций потому, что он их ищет прежде, чем обрабатывает любые параметры командной строки.
MySQL читает заданные по умолчанию параметры из следующих файлов (только в ОС Windows):
| Имя файла | Зачем он нужен |
| windows-system-directory\my.ini | Глобальные опции |
| C:\my.cnf | Глобальные опции |
| C:\mysql\data\my.cnf | Опции для сервера |
Обратите внимание, что в Windows Вы должны определить все пути с / вместо \ . Если Вы используете \ , Вы должны определить это дважды, поскольку \ символ ESC в MySQL.
MySQL пробует читать файлы опции в порядке, перечисленном выше. Если есть несколько файлов настроек, используется опция, определенная в том файле, который читается позже. Параметры, определенные в командной строке имеют приоритет над параметрами, определенными в любом файле опций. Некоторые параметры могут быть определены, используя системные переменные. Параметры, определенные в командной строке или в файлах опций имеют приоритет над значением соответствующей системной переменной.
Следующие программы поддерживают файлы опций: mysql , mysqladmin , mysqld , mysqldump , mysqlimport , mysql.server , myisamchk и myisampack .
Вы можете использовать файлы опций, чтобы определить любую длинную опцию, которую программа поддерживает! Выполните программу с параметром --help , чтобы получить список доступных параметров.
Файл опций может содержать строки следующих форм:
Группа client позволяет Вам определять параметры, которые обращаются ко всей клиентуре MySQL (но не к mysqld ). Это самая подходящая группа, чтобы определить в ней пароль, который Вы используете, чтобы соединиться с сервером. Но удостоверьтесь, что файл опций читаем и перезаписываем только Вами.
Обратите внимание, что для параметров и значений все конечные и начальные пробелы автоматически удалены. Вы можете использовать управляющие последовательности \b , \t , \n , \r , \\ и \s в Вашей строке ( \s ==пробел).
Имеется типичный глобальный файл опций:
Имеется типичный файл опций пользователя:
Если Вы имеете дистрибутив с исходниками, Вы найдете, что типовые файлы конфигурации называются my-xxxx.cnf в каталоге support-files . А вот в двоичном дистрибутиве смотрите в каталог DIR/support-files , где DIR задает имя пути к каталогу установки MySQL (обычно /usr/local/mysql ). В настоящее время имеются типовые файлы конфигурации для маленькой, средней, большой и очень большой системы. Вы можете копировать my-xxxx.cnf в Ваш основной каталог (переименуйте копию в .my.cnf ), чтобы экспериментировать.
Вся клиентура MySQL, которая поддерживает файлы опций, использует и следующие параметры:
| --no-defaults | Не читать любые файлы опций. |
| --print-defaults | Печатать имя программы и все параметры, которые ей передаются. |
| --defaults-file=full-path-to-default-file | Использовать только данный файл конфигурации. |
| --defaults-extra-file=full-path-to-default-file | Читать этот файл конфигурации после глобального файла опций, но перед чтением файла настроек пользователя. |
Обратите внимание, что вышеупомянутые параметры должны быть первыми в командной строке, чтобы они работали! Однако, --print-defaults может использоваться непосредственно после команды --defaults-xxx-file .
В скриптах оболочки Вы можете использовать команду my_print_defaults , чтобы анализировать файлы конфигурации:
Вышеупомянутый вывод содержит все параметры для групп 'client' и 'mysql'.
В некоторых случаях Вы можете хотеть иметь много различных серверов mysqld на одной машине. Вы можете, например, выполнять новую версию MySQL для тестирования вместе со старой версией, которая находится в постоянном рабочем использовании. Другой случай: Вы хотите давать различным пользователям доступ к разным серверам mysqld , которыми они будут управлять самостоятельно.
Один способ получить новый сервер: запустить его с другим сокетом и портом следующим образом:
Приложение системных переменных включает список других системных переменных, которые Вы можете использовать, чтобы воздействовать на mysqld . Подробности в разделе "Приложение 2. Переменные окружения ".
Если Вы должны делать это более постоянно, Вы должны создать файл опций для каждого сервера. Подробности в разделе "4.1.2 Файлы опций my.cnf". В Вашем скрипте запуска, который будет выполнен при начальной загрузке (mysql.server?), Вы должны определить для обоих серверов:
По крайней мере следующие параметры должны быть различны на серверах:
Следующие параметры должны быть различны, если они используются:
log=path log-bin=path log-update=path log-isam=path bdb-logdir=path
Если Вы хотите получить большую эффективность, Вы можете также определять:
Если Вы устанавливаете двоичные версии MySQL (файлы .tar) и запускаете их с ./bin/safe_mysqld , то обычно придется менять только опции socket и port в скрипте safe_mysqld .
Имеются обстоятельства, когда Вы могли бы хотеть выполнять много серверов на одной и той же машине. Например, Вы могли бы проверять новый выпуск MySQL при оставлении Вашей существующей безмятежной установки в рабочем состоянии.
Если Вы хотите выполнять много серверов, самый простой путь состоит в том, чтобы компилировать их с различными портами TCP/IP и файлами сокетов так, что они оба не слушают тот же самый порт TCP/IP или файл сокета.
Предположим, что существующий сервер конфигурирован для заданного по умолчанию номера порта и файла сокета. Теперь конфигурируйте новый сервер командой выбора конфигурации configure :
Здесь port_number и file_name должны отличаться от заданных по умолчанию номера порта и имени пути файла сокета, значение --prefix должно определить другой каталог установки, а не тот, в котором размещена существующая установка MySQL.
Вы можете проверять сокет, используемый любым в настоящее время выполняющимся сервером MySQL, командой:
Обратите внимание, что, если Вы определяете localhost как имя хоста по умолчанию, mysqladmin будет использовать Unix-сокеты вместо протокола TCP/IP.
Если Вы имеете сервер MySQL, работающий на уже занятом порте, Вы получите список из наиболее важных переменных настройки в MySQL, включая имя сокета.
Вы не должны перекомпилировать сервер MySQL только, чтобы запустить его с другого порта и сокета. Вы можете изменять порт и сокет, который нужно использовать, определяя их во время выполнения как параметры для safe_mysqld :
mysqld_multi может также брать safe_mysqld (или mysqld ) как параметр и передавать параметры из файла конфигурации safe_mysqld и в дополнение mysqld .
Если Вы выполняете новый сервер в том же самом каталоге баз данных, что и старый с включенным протоколированием, Вы должны также определить имя журналов в safe_mysqld с помощью опций --log , --log-update или --log-slow-queries . Иначе оба сервера могут попробовать вести протокол в одни и те же файлы!
ПРЕДУПРЕЖДЕНИЕ: Обычно Вы никогда не должны иметь двух серверов, которые модифицируют данные в той же самой базе данных! Если Ваша ОС не поддерживает полноценную блокировку системы, это легко может привести к ОЧЕНЬ неприятным неожиданностям!
Если Вы хотите использовать другой каталог баз данных для второго сервера, Вы можете использовать опцию --datadir=path при вызове safe_mysqld .
ОБРАТИТЕ ВНИМАНИЕ также, что запуск нескольких серверов MySQL ( mysqlds ) на различных машинах и разрешение им обращаться в один каталог данных через NFS вообще ПЛОХАЯ ИДЕЯ ! Проблема состоит в том, что NFS станет узким местом с низким быстродействием. Этот сервис не предполагается для такого использования. К тому же Вам придется придумывать решение, как надежно удостовериться, что два или больше процессов mysqld не сталкиваются друг с другом. В настоящее время не имеется никакой платформы, которая была бы 100% надежной, чтобы делать блокировку файла (обычно lockd daemon) в любой ситуации. Все же имелся бы еще один возможный риск с NFS : этот сервис сделал бы работу для lockd еще более сложной. Так что забудьте о таких развлечениях! Рабочее решение состоит в том, чтобы иметь один компьютер с операционной системой, которая эффективно обрабатывает потоки, и иметь в нем несколько CPU и памяти побольше.
Когда Вы хотите соединиться с сервером MySQL, который работает с другим портом, чем порт, который компилируется в Вашего клиента, Вы можете использовать один из следующих методов:
Последнее время пришлось заняться оптимизацией своего VDS на RuWEB. Нет всё нормально, но любой проект время от времени требует обновления дизайна, оптимизации таблиц, вообщем ТО. В частности пришлось заняться оптимизацией MySQL . Раньше никогда этим заниматься не приходилось. Всё делаю по результатам гугления и эти заметки нового врядли что-то дадут человеку опытному. Скорее эаметки для себя. Но кто его знает. Комментарии приветствуются.
Перезагрузка MySQL
Первая проблема с которой столкнулся нормальная перезагрузка сервиса MySQL из Putty. Большинство советов в сети не работали у RuWEB. Там FreeBSD 8 и MySQL 5. Ответ нашел на форуме у RuWEB, практически в факе.
/usr/local/etc/rc.d/mysql-server restart — перезапуск mysql
/usr/local/etc/rc.d/mysql-server start — запуск mysql
/usr/local/etc/rc.d/mysql-server stop — остановка mysql
Где лежит my.cnf
Все настройки MySQL прописываются в файле my.cnf . Вот только кладут его в разные места. У меня он лежит в /etc ( полный путь /etc/my.cnf )
Диагностика MySQL
Глупо менять множество параметров в my.cnf в слепую. Озадачился поиском способа диагностики и поиска узких мест MySQL.
1. Есть стандартная утилита mysqladmin . Она не то чтобы предназначена для оптимизации, она для администрирования сервера MySQL. Но может дать весьма полезную информацию во время комплекса мер по оптимизации MySQL.
Например:
mysqladmin -u root –pВАШ_ПАРОЛЬ status
— состояние сервера MySQL
mysqladmin -u root — pВАШ_ПАРОЛЬ variables
— вывод переменных my.cnf
Команды mysqladmin можно комбинировать.
mysqladmin -u root — pВАШ_ПАРОЛЬ process status version
2. Есть классная утилита mysqltuner.pl . Она мало того что элементарно устанавливается и работает, анализирует работу сервера MySQL, так ещё и выводит рекомендации по оптимизации MySQL. В простом и доступном виде, что не маловажно если оптимизация разовая процедура ( мой случай ). Надо отметить что рекомендации этой утилиты тем точнее, чем дольше работает сервер MySQL. То есть если вы только что перезапустили сервер, то запускать mysqltuner.pl смысла не много. Дайте серверы поработать хотя бы сутки.
Запускаем:
perl mysqltuner.pl
Вводим логин/пароль. Утилита дает вывод, а в конце рекомендации по обслуживанию сервера MySQL и изменению конкретных переменных в MySQL.
Файл конфигурации содержит параметры, связанные с системой или приложением. Это дает разработчикам и администраторам управлять работой этой системы или приложением.
Как системный администратор Linux, знание местоположения конфигурационных файлов или способов овладения ими является неоценимым навыком.
В структуре каталогов Linux, каталог /etc или его подкаталоги, хранят связанные с системой файлы или файлы конфигураций.
Хотя это основное расположение файлов конфигурации, некоторые разработчики предпочитают хранить другие файлы конфигурации в пользовательских каталогах.
Как найти файл конфигурации MySQL (my.conf)
Вы можете найти файл конфигурации MySQL с помощью инструмента командной строки mysql или mysqladmin.
Следующие команды будут отображать страницу справки mysql или mysqladmin, которая содержит раздел, где рассказывается о файлах (файлах конфигурации), из которых считываются параметры по умолчанию.
Дальше будет приведена команда grep, которая имеет параметр -A, он отображает NUM (кол-во) строк конечного контекста после сопоставления строк.
Как найти файл конфигурации PHP (php.ini)
PHP можно управлять с терминала с помощью утилиты командной строки php в сочетании с параметром -i, который позволяет показывать информацию и конфигурацию PHP. Также есть команда grep, она нужна, чтоб вы могли найти файл конфигурации PHP следующим образом:
На Debian/Ubuntu/Linux Mint
Спасибо за уделенное время на прочтение статьи!
Если возникли вопросы, задавайте их в комментариях.
Подписывайтесь на обновления нашего блога и оставайтесь в курсе новостей мира инфокоммуникаций!
Чтобы знать больше и выделяться знаниями среди толпы IT-шников, записывайтесь на курсы Cisco от Академии Cisco, курсы Linux от Linux Professional Institute на платформе SEDICOMM University.
Читайте также: