Комментарии 50
Сейчас MySQLConfigurer поддерживает MySQL версий 5.5, 5.6 и 5.7
Когда планируется поддержка 8.0? А то 8-ка официально пригодна к использованию с 19.04.2018
P.S. У нас проект на 8-ке с апреля 18-го, полёт нормальный
UPDATE: MySQLTuner уже поддерживает
Дело в том, что сейчас проект используется в поддержке нескольких десятков серверов MySQL для автоматизации работы инженеров. Большинство из этих серверов имеют версию 5.5 — 5.7.
Поэтому до 8-ки еще и не добрались, но по мере развития проекта планируем добавить.
Добавил issue на github по поддержке MySQL 8.
Поэтому до 8-ки еще и не добрались, но по мере развития проекта планируем добавить.
Добавил issue на github по поддержке MySQL 8.
Чем обоснована необходимость отправлять репорт MySQLTuner на сторонний сервис (https://api.servers-support.com/v1/mysql)?
Было бы лучше локально парсить репорт и билдить предлагаемый конфиг локально...
У MySQLTuner особенность в том, что он делает выводы на основе среза информации о MySQL, который получен в данный момент времени. Но есть понимание, что зная исторические данные можно точнее настраивать конфигурацию и в перспективе лучше, чем инженер. Поэтому и был предложен именно такой формат взаимодействия.
В текущей версии не используются исторические данные, но над этим работаем.
Документацию будем развивать и больше публиковать информации о методике расчета параметров.
В текущей версии не используются исторические данные, но над этим работаем.
Документацию будем развивать и больше публиковать информации о методике расчета параметров.
Однако при этом на ваш сервис уходит пароль, который вводится в консоли…
Спасибо, за информацию.
Инженеры подтвердили, если пароль для MySQL вводится вручную, то этот пароль MySQLTuner сохраняет в отчете JSON в разделе «MySQL Client». В случае если используется файл с данными для подключения пароль не сохраняется и не передается.
Информацию из этого раздела мы не используем для обработки и исторического анализа метрик, поэтому сейчас готовим обновление для исключения сбора этой информации и удаления ее в ранее собранных отчетах.
Инженеры подтвердили, если пароль для MySQL вводится вручную, то этот пароль MySQLTuner сохраняет в отчете JSON в разделе «MySQL Client». В случае если используется файл с данными для подключения пароль не сохраняется и не передается.
Информацию из этого раздела мы не используем для обработки и исторического анализа метрик, поэтому сейчас готовим обновление для исключения сбора этой информации и удаления ее в ранее собранных отчетах.
И еще — понятно, что это не ваш баг, но mysqltuner пытается получить данные через hostname -I. Проблема в том, что у меня на сервере hostname не понимает -I, ему вместо этого надо дать -i. Вручную подправить две строчки в скрипте — не проблема, но он каждый раз скачивается заново. Это действительно необходимо — каждый раз качать сторонний скрипт?
Ну и с mariaDB 10.4 так ничего и не решено. Тюнер отрабатывает, а потом — ох, ах, 500
Ну и с mariaDB 10.4 так ничего и не решено. Тюнер отрабатывает, а потом — ох, ах, 500
Скачивать каждый раз необходимости особой нет, но планировали чтобы он был актуальный. Информацию принял и завел issue на эту тему. Мы обсудим и дадим обратную связь.
Да, работы по новым версиям ведутся, но медленно. Много проделали работы по улучшению качества конфигурационных файлов MySQL для старых версий.
Да, работы по новым версиям ведутся, но медленно. Много проделали работы по улучшению качества конфигурационных файлов MySQL для старых версий.
к вопросу о hostname уточните какая у Вас операционная система и какая версия?
Добавлена поддержка MySQL 8, MariaDB 10.4, MariaDB 10.5. Можно пробовать.
Исправили, теперь Mysqltuner каждый раз не скачивается.
Ссылку на страницу проекта поправьте?
MySQLTuner в основном нужен для начальной настройки и понимания взаимосвязи опций. В последствии ориентироваться лучше на тот же PMM(percona monitoring and management)
Мы провели тесты MySQL с помощью Sysbench на виртуальном сервере с операционной системой Debian 9 (2 CPU, 2GB Ram) на таблице в 10 млн. записей.
Было бы интересно посмотреть тесты на более серьезном железе.
синтетика — такая синтетика…
Честно, говоря, даже не задумывался, пилил себе сайт на работе для работы и ладно.
Но результат вашего скрипта просто ошеломил — если без него один тяжелый api запрос выполнялся 350-400мс, то после оптимизации — 130-170мс. Это даже больше, чем двухкратный прирост на рабочей БД. Хотя, конечно, это только один запрос, другой показал рост примерно на 30%, а кучу мелких даже проверять не стал. Тем более, что все это прогоняется через apache+php. Но все равно заметно сильно, сайт отзывчивее стал
Честно, говоря, даже не задумывался, пилил себе сайт на работе для работы и ладно.
Но результат вашего скрипта просто ошеломил — если без него один тяжелый api запрос выполнялся 350-400мс, то после оптимизации — 130-170мс. Это даже больше, чем двухкратный прирост на рабочей БД. Хотя, конечно, это только один запрос, другой показал рост примерно на 30%, а кучу мелких даже проверять не стал. Тем более, что все это прогоняется через apache+php. Но все равно заметно сильно, сайт отзывчивее стал
Спасибо за обратную связь.
Нам такой результат, как бальзам на душу. Для этого и работаем.
Нам такой результат, как бальзам на душу. Для этого и работаем.
Но ложка дегтя тоже есть, обнаружилась сегодня — начали отваливаться коннекты, которые раьше могли сутками висеть. Заподозрил это
пока вернул старые значения, посмотрим, как будет себя вести
interactive_timeout = 1200 ### Previous value : 28800
wait_timeout = 1200 ### Previous value : 28800пока вернул старые значения, посмотрим, как будет себя вести
Проблему с таймаутами исправили в последнем релизе github.com/Releem/mysqlconfigurer/releases/tag/0.5.0
Скрипт выполнялся 2 часа, в z_aiops_mysql.cnf {«message»: «Internal server error»}
Спасибо, что дали обратную связь. Сейчас такое поведение в основном связано с тем, что:
1. мы пока не поддерживаем MySQL версии 8.
2. MySQLTuner не смог собрать корректный отчет. (в основном из-за того что прав не достаточно)
Проверили запросы поступающие на сервис, но за последнее время не увидели ошибочных. Уточните, пожалуйста, когда и во сколько примерно делали запрос к сервису?
1. мы пока не поддерживаем MySQL версии 8.
2. MySQLTuner не смог собрать корректный отчет. (в основном из-за того что прав не достаточно)
Проверили запросы поступающие на сервис, но за последнее время не увидели ошибочных. Уточните, пожалуйста, когда и во сколько примерно делали запрос к сервису?
К сожалению не могу сказать. может поможет отчет был около 7Мб.
Сейчас вот это выдал:
# 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
# 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
Проблему увидели.
В данном случае формат данных отчета MySQLTuner для percona отличается от тех на которых мы проводили тестирование (MySQL 5.5, 5.6 и 5.7).
Создал issue по этой проблеме. Я отпишусь тут по решению.
В данном случае формат данных отчета MySQLTuner для percona отличается от тех на которых мы проводили тестирование (MySQL 5.5, 5.6 и 5.7).
Создал issue по этой проблеме. Я отпишусь тут по решению.
Пока не понятно по какой причине, но в Вашем случае при запуске MySQLTuner была установлена опция skipsize, в результате в отчет не попала информация о размерах данных в используемых механизмах хранения MySQL. Уточните, пожалуйста, Вы редактировали скрипт или запускали как есть?
Да, я добавлял эту опцию. Хотел сократить время работы скрипта.
Попробуйте, пожалуйста, не добавлять эту опцию, потому что без этих данных не сможем расчет сделать.
Уточните, а почему хотели сократить время выполнения скрипта, может во время работы скрипт сильно нагружает систему?
Запустил снова, на этот раз без --skipsize. Выполнялся 2 часа.
В итоге {«message»: «Internal server error»}
У меня много баз (~2.5К), по поводу нагрузки — нет не грузит, только диск теребит.
В итоге {«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, поэтому пока он не может заменить полностью ручной процесс оптимизации.
Все замечания обсудим с командой и добавим соответствующие Issue.
Уточните, пожалуйста, во сколько по времени Вы делали запрос к сервису для более детального анализа? (можно в личку)
Поддерживается ли MariaDB?
Ндааа...
"Спасибо" за зря потраченное время.
Можно было бы сразу сказать что сервис платный, а из бесплатного там полезного ровно 0.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматическая настройка и оптимизация сервера MySQL для повышения производительности