Comments 14
UFO just landed and posted this here
Для себя нашел статью интересной, но ряд советов из неё без пояснений можно смело назвать вредными.
К примеру советы про пул буферов. Для того чтобы менять параметры по сбросу буферного пула на диск и созданию множества пулов буферов, надо хотя бы в начале в performance_schema (к примеру) или в других средствах диагностики увидеть множественные ожидания мьютексов буферного пула. Каждый буферный пул имеет свой мьютекс и свой LRU список адресов загруженных в память буферов. Если в вашей системе всего 4 ядра, но индексы базы занимают 100Gb, вы никак не сможете работать с множеством буферных пулов. Просто не хватит процессоров или дисков, чтобы читать 4 LRU списка одновременно. А вот на 16 ядерной машине с 20 HDD конечно смысл имеется.
В пул буферов при пессимистическом раскладе должны помещатся не все файлы данных а хотя бы их индексы. Ибо для чего вам тогда HDD?
Увеличение размера табличного кэша без увеличения соответствующих настроек ОС невозможно (но вы увидете в логах предупреждение что этот параметр проигнорирован). При выставлении этого параметра в слишком большие значения более 20000 надо быть аккуратным. Ибо в кэше поиск происходит линейно. Есть шанс, что вы отгребете проблемы с поиском таблицы уже в нем.
Кидать временные файлы на диск в ОЗУ надо аккуратнее. Ибо файловая система tmpfs не поддерживает innodb. Завалите себе весь лог ошибками. Можно использовать только если во временных таблицых вы используете memory и myisam движки.
К примеру советы про пул буферов. Для того чтобы менять параметры по сбросу буферного пула на диск и созданию множества пулов буферов, надо хотя бы в начале в performance_schema (к примеру) или в других средствах диагностики увидеть множественные ожидания мьютексов буферного пула. Каждый буферный пул имеет свой мьютекс и свой LRU список адресов загруженных в память буферов. Если в вашей системе всего 4 ядра, но индексы базы занимают 100Gb, вы никак не сможете работать с множеством буферных пулов. Просто не хватит процессоров или дисков, чтобы читать 4 LRU списка одновременно. А вот на 16 ядерной машине с 20 HDD конечно смысл имеется.
В пул буферов при пессимистическом раскладе должны помещатся не все файлы данных а хотя бы их индексы. Ибо для чего вам тогда HDD?
Увеличение размера табличного кэша без увеличения соответствующих настроек ОС невозможно (но вы увидете в логах предупреждение что этот параметр проигнорирован). При выставлении этого параметра в слишком большие значения более 20000 надо быть аккуратным. Ибо в кэше поиск происходит линейно. Есть шанс, что вы отгребете проблемы с поиском таблицы уже в нем.
Кидать временные файлы на диск в ОЗУ надо аккуратнее. Ибо файловая система tmpfs не поддерживает innodb. Завалите себе весь лог ошибками. Можно использовать только если во временных таблицых вы используете memory и myisam движки.
Спасибо за полезный комментарий!
Многое действительно не описали подробно, а лишь «задали направление», так как при детальном описании получится не статья на Хабр, а книга High Performance MySQL. :)
Все-таки рассчитываем не на cut-n-paste конфигов, а на более детальное изучение.
Многое действительно не описали подробно, а лишь «задали направление», так как при детальном описании получится не статья на Хабр, а книга High Performance MySQL. :)
Все-таки рассчитываем не на cut-n-paste конфигов, а на более детальное изучение.
В данном случае видимо идет речь о временных таблицах создаваемых автоматически на диске, которые, как известно, имеют формат MyISAM:
dev.mysql.com/doc/refman/5.5/en/internal-temporary-tables.html
В движке Битрикс временные таблицы сознательно не создаются.
dev.mysql.com/doc/refman/5.5/en/internal-temporary-tables.html
В движке Битрикс временные таблицы сознательно не создаются.
>Файловая система tmpfs не поддерживает innodb
Э-э-э… поясните?!
Э-э-э… поясните?!
Спасибо. А для тех, кто уже долго и с удовольствием пользуется Битриксом есть плюшки?
Например? :)
Видимо, стартовавшая сегодня акция? www.1c-bitrix.ru/about/life/news/486531/ (сорри за оффтопик...)
Видимо, стартовавшая сегодня акция? www.1c-bitrix.ru/about/life/news/486531/ (сорри за оффтопик...)
Простите что не совсем по теме, но кто знает похоже, детализированное руководство от практиков по PostgreSQL?
Тут есть с чем поспорить и что дополнить.
1. Query Cache — полезно её периодически дефрагментировать при помощи FLUSH QUERY CACHE
2. Когда меняете innodb_flush_method — обязательно тестируйте! Я видела немало примеров, когда люди взяли подобный пример из статьи с тем чтобы после удивляться, почему InnoDB работает не так быстро как им хочется.
3. innodb_file_per_table рекомендуется использовать и на обычном MySQL. Хотя бы затем, чтоб в случае проблем одну табличку из дампа восстановить легче, чем все. Удобнее бинарные бэкапы делать, опять-таки (MEB, Xtrabackup)
4. > В Перконе можно использовать опцию innodb_corrupt_table_action = assert,…
В версии 5.5 есть опция innodb_force_load_corrupted
1. Query Cache — полезно её периодически дефрагментировать при помощи FLUSH QUERY CACHE
2. Когда меняете innodb_flush_method — обязательно тестируйте! Я видела немало примеров, когда люди взяли подобный пример из статьи с тем чтобы после удивляться, почему InnoDB работает не так быстро как им хочется.
3. innodb_file_per_table рекомендуется использовать и на обычном MySQL. Хотя бы затем, чтоб в случае проблем одну табличку из дампа восстановить легче, чем все. Удобнее бинарные бэкапы делать, опять-таки (MEB, Xtrabackup)
4. > В Перконе можно использовать опцию innodb_corrupt_table_action = assert,…
В версии 5.5 есть опция innodb_force_load_corrupted
Подскажите: насколько понимаю, в системе, настроенной при помощи repos.1c-bitrix.ru/yum/bitrix-env.sh (грубо — взяли Centos 6.x x64, поставили по дефолту, скачали упомянутый скрипт, запустили, подождали), есть скрипты, автоматически оптимизирующие сервисы на машине под разные размеры памяти — так вот эти оптимизации и приведенные здесь примеры настроек (точнее, мудрость настроек) имеют что-то общее, либо (если полагать, что машина, раз настроенная, постоянно не будет запускаться с разным объемом ОЗУ) отрубаем скрипты, и начинаем тюнить машинку уже по этой статье?
«Веб-окружение» — пакет, предназначенный для быстрого разворачивания готового к использованию веб-стека приложений. В основном, для средних проектов.
Серьезные крупные приложения под высокой нагрузкой все равно потребуют того или иного тюнинга для конкретных условий (объем данных, характер запросов и т.п.)
Серьезные крупные приложения под высокой нагрузкой все равно потребуют того или иного тюнинга для конкретных условий (объем данных, характер запросов и т.п.)
Sign up to leave a comment.
Еще 12 «рецептов приготовления» MySQL в Битрикс24