:) выпускает краснодарская компания Initlab.

Замечание по поводу innodb_flush_log_at_trx_commit принял, сейчас issue сделаю.

Рекомендации сейчас делаются исходя из максимальной производительности - обкатка была на различных проектах - но работы еще много. Это ранняя альфа.

В Вашем случае я так понимаю также критичен вопрос максимальной сохранности транзакций в случае сбоя, поэтому innodb_flush_log_at_trx_commit важен в 1.

Спасибо, что посмотрели.

да тут нет замечания. Есть уверенность бесполезности попытки распространять свою так называемую экспертизу на все применения mysql.
В mysql ничего не сломано из коробки. Что вы пытаетесь оптимизировать?

Может быть в качестве оптимизатора друпала или отдельных приложений под конкретными названиями такое бы и взлетело

но для этого надо собирать побольше данных с сервера) а это уже никто не отдаст

могу книжку сфоткать. там по бумажному написано "вы не сможете оптимизировать mysql одними настройками, не старайтесь"

Да, действительно тут вопрос распространения экспертизы.

Вызван был тем, что постоянно проводим аудиты производительности различных проектов, и сейчас как минимум пробуем автоматизировать вопрос принятия решения по значению параметров на основе алгоритма исходя из значения статусов MySQL.

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

высшей школе КГБ зачот за попытку внедрения и работу  с новыми технологиями)

В чем прикол постоянно задрачивать конфиг мускуля?

Ну там все приходят с друпалом и битриксом

господа помахите

Я то думал, что нужен конфиг обеспечивающий оптимальную производительность и стабильность. Который через год-два будет доработан под текущую ситуацию и железа.

не только , но в целом это веб приложения. От Друпал и Битрикс до крупных федеральных проектов на микросервисной архитектуре.

да хер из знает на самом деле.
погроммистов хлебом не корми, дай какой-нибудь стартап закодить.

даже если он бессмысленный и беспощадный

Дело в том, что разработка приложения ведется постоянно и следить за оптимальностью конфига приходится чаще)))

Задродство какое-то, чес слово.
Либо попытка изучить мускуль тыкая в него палочками. Упадет или нет.

Тем самым вы ещё больше грузите админа по базам, которому постоянно смотреть что на этот раз изменилось в конфиге

ну скрипту mysqltuner.pl многие верят.
а тут попытка подсобрать эти же данные,  что-нибудь обобщить и родить универсальные правила.
только, мне кажется, обобщать нечего.

А оно учитывает разные баги разных версий мускуля и изменения кода в пределах релиза?

Ну почитай  скрипт) он же в исходниках

Лень)