Комментарии 50
Сейчас MySQLConfigurer поддерживает MySQL версий 5.5, 5.6 и 5.7
Когда планируется поддержка 8.0? А то 8-ка официально пригодна к использованию с 19.04.2018
P.S. У нас проект на 8-ке с апреля 18-го, полёт нормальный
UPDATE: MySQLTuner уже поддерживает
Поэтому до 8-ки еще и не добрались, но по мере развития проекта планируем добавить.
Добавил issue на github по поддержке MySQL 8.
Чем обоснована необходимость отправлять репорт MySQLTuner на сторонний сервис (https://api.servers-support.com/v1/mysql)?
Было бы лучше локально парсить репорт и билдить предлагаемый конфиг локально...
В текущей версии не используются исторические данные, но над этим работаем.
Документацию будем развивать и больше публиковать информации о методике расчета параметров.
Инженеры подтвердили, если пароль для MySQL вводится вручную, то этот пароль MySQLTuner сохраняет в отчете JSON в разделе «MySQL Client». В случае если используется файл с данными для подключения пароль не сохраняется и не передается.
Информацию из этого раздела мы не используем для обработки и исторического анализа метрик, поэтому сейчас готовим обновление для исключения сбора этой информации и удаления ее в ранее собранных отчетах.
Ну и с mariaDB 10.4 так ничего и не решено. Тюнер отрабатывает, а потом — ох, ах, 500
Да, работы по новым версиям ведутся, но медленно. Много проделали работы по улучшению качества конфигурационных файлов MySQL для старых версий.
Мы провели тесты MySQL с помощью Sysbench на виртуальном сервере с операционной системой Debian 9 (2 CPU, 2GB Ram) на таблице в 10 млн. записей.
Было бы интересно посмотреть тесты на более серьезном железе.
Честно, говоря, даже не задумывался, пилил себе сайт на работе для работы и ладно.
Но результат вашего скрипта просто ошеломил — если без него один тяжелый api запрос выполнялся 350-400мс, то после оптимизации — 130-170мс. Это даже больше, чем двухкратный прирост на рабочей БД. Хотя, конечно, это только один запрос, другой показал рост примерно на 30%, а кучу мелких даже проверять не стал. Тем более, что все это прогоняется через apache+php. Но все равно заметно сильно, сайт отзывчивее стал
Нам такой результат, как бальзам на душу. Для этого и работаем.
interactive_timeout = 1200 ### Previous value : 28800
wait_timeout = 1200 ### Previous value : 28800
пока вернул старые значения, посмотрим, как будет себя вести
1. мы пока не поддерживаем MySQL версии 8.
2. MySQLTuner не смог собрать корректный отчет. (в основном из-за того что прав не достаточно)
Проверили запросы поступающие на сервис, но за последнее время не увидели ошибочных. Уточните, пожалуйста, когда и во сколько примерно делали запрос к сервису?
# 500 Internal Server Error Oh no! Something bad happened. Please check supported MySQL versions. Thanks.
Версия mysql: percona-server-server-5.6 5.6.39-83.1-1.bionic
В итоге {«message»: «Internal server error»}
У меня много баз (~2.5К), по поводу нагрузки — нет не грузит, только диск теребит.
Я хостер (и мы умеем тюнить мускль). Любопытства ради запустил скрипт на одном из продакшн серверов (сотни БД, десятки гигабайт, перкона 5.6). Результат, ну, удивляет.
query_cache_type = 1 ### Previous value: OFF
При этом точно известно, что на нашей нагрузке это приводит к конкуренции за кеш запросов, блокировкам на нем и вообще-то работоспособность сервера на этом заканчивается минуты за три, вроде.
interactive_timeout = 1200 ### Previous value: 70
wait_timeout = 1200 ### Previous value: 70
Мы уменьшаем эти таймауты до 70, чтобы было меньше подвисших коннектов, особенно для плохо написанных сайтов. Увеличение до 1200 приводит к разрастанию числа коннектов в мускле и его полной недоступности примерно за час.
table_open_cache = 65536 ### Previous value: 131072
Непонятное косметическое изменение, которое противоречит логике — таблиц там сильно за 64к было. mysqltuner предлагает: table_open_cache (> 131072), кстати.
innodb_buffer_pool_instances = 42 ### Previous value: 2
innodb_buffer_pool_size = 45097156608 ### Previous value: ...
Ну, кого волнует сколько вообще памяти на сервере и зачем она там ему? 42 потока на 4 ядрах (+HT), почему бы и нет, правда?
Бонусом — косметические правки по myisam, который на сервере практически не используется.
В общем, подтюнить в мускле можно многое, но в основном не теми параметрами, что делает этот скрипт. А результаты этого скрипта определенно нельзя копировать в продакшн не вчитываясь в детали.
Но инициатива, безусловно, отличная, хотелось бы пожелать дальнейшего развития и работы с менее очевидными параметрами )
Проект молодой и больше позиционируем его, как первый шаг на пути оптимизации MySQL, поэтому пока он не может заменить полностью ручной процесс оптимизации.
Все замечания обсудим с командой и добавим соответствующие Issue.
Уточните, пожалуйста, во сколько по времени Вы делали запрос к сервису для более детального анализа? (можно в личку)
Задача по поддержки более новых версий и MySQL 8 пока ещё в работе.
Текущие поддерживаемые версии:
- MySQL 5.7
- MySQL 5.6
- MySQL 5.5
- MariaDB 10.1
- MariaDB 10.2
- MariaDB 10.3
Ндааа...
"Спасибо" за зря потраченное время.
Можно было бы сразу сказать что сервис платный, а из бесплатного там полезного ровно 0.
Автоматическая настройка и оптимизация сервера MySQL для повышения производительности