Размещаем в Амазоне наш сервис Битрикс24 — социальный интранет, SaaS-сервис, объединяющий в себе классические инструменты командной работы (календари, задачи, CRM, работа с документами) и социальные коммуникации («лайки», социальный поиск, мгновенные сообщения).
Активно используем связку ELB + AutoScaling + CloudWatch. S3 — для хранения данных. Снэпшоты для бэкапов.
«Веб-окружение» — пакет, предназначенный для быстрого разворачивания готового к использованию веб-стека приложений. В основном, для средних проектов.
Серьезные крупные приложения под высокой нагрузкой все равно потребуют того или иного тюнинга для конкретных условий (объем данных, характер запросов и т.п.)
Многое действительно не описали подробно, а лишь «задали направление», так как при детальном описании получится не статья на Хабр, а книга High Performance MySQL. :)
Все-таки рассчитываем не на cut-n-paste конфигов, а на более детальное изучение.
# Joins
if ($mycalc{'joins_without_indexes_per_day'} > 250) {
badprint "Joins performed without indexes: $mycalc{'joins_without_indexes'}\n";
push(@adjvars,"join_buffer_size (> ".hr_bytes($myvar{'join_buffer_size'}).", or always use indexes with joins)");
push(@generalrec,"Adjust your join queries to always utilize indexes");
} else {
...
Если не будет индексов (зачастую — составных, которые надо построить самим), то он, видимо, всегда так будет рапортовать. :)
И «join_buffer_size = 8G» — это в любом случае плохо. Вот неплохое описание (с комментариями), как происходит выделение памяти для join_buffer_size:
Если вы столь искренне переживаете за наш продукт, расскажите о ваших переживаниях там, где это будет уместно. Лично Рыжикову (его e-mail, твиттер, фейсбук не являются тайной; на конструктивную критику он всегда реагирует), на сайте idea.1c-bitrix.ru/ (его читают все наши разработчики), создайте обращение в тех. поддержку или напишите лично ее руководителю (все контакты тоже доступны).
Эта статья — о практиках использования MySQL. Для любых проектов, на Битриксе они сделаны или нет.
Если вы как на красную тряпку реагируете именно на слово «битрикс», тут уж ничего не поделаешь — так уж сложилось, что в данном случае практическим опытом делимся именно мы. И очень верю, что для многих он — полезен.
Это подразумевается по умолчанию. И об этом как раз говорится в предыдущей статье, на которую я несколько раз ссылался: habrahabr.ru/company/bitrix/blog/146490/
В противном случае «м-м» в принципе не будет работать.
Но даже с настроенными auto_increment_increment и auto_increment_offset «Duplicate entry» все равно будут. Один из возможных сценариев появления такой ошибки как раз описан в статье.
— Сессии (в итоге, после разных экспериментов) тоже храним в мемкеше. Правда, потребовалась некоторая доработка логики, чтобы реализовать собственный механизм локировок (в мемкеше его нет).
— xtrabackup тоже используем, но для других сценариев. Снэпшот и образ машины делаются сильно проще и быстрее. Да и разворачивать их потом тоже легче.
Рад, что вам нравится наш редактор с подсветкой! И, кстати, для истинных ценителей есть еще несколько схожих по функционалу модулей в нашем маркетплейсе:
Подобная конфигурация (Master-Master + переключение трафика) не только защищает от простоев во время аварий, но и очень помогает при проведении любых работ с базой (установка апдейтов, переконфигурирование и т.п.) — без даунтайма для клиентов.
Windows 95 ставилась с дискет. Их вполне себе за несколько ночей можно было выкачать с BBS или из фидошных файл-эх. Ну, или взять у приятелей, которые это уже проделали. ;)
Мне кажется, наше предложение получилось как раз неплохим. До 12 человек — бесплатно. Больше — ну, это, на мой взгляд, уже не такая уж и маленькая компания… :)
Все эти сервисы тоже же не дураки, раз расплодились в таком количестве? :))
Если серьезно — все разные по функционалы. Да, конечно, так или иначе пересекаются многие. Но у всех своя «фишка».
Далее — важна конкуренция. Она очень хорошо стимулирует на развитие. Вы же вряд ли будете возмущаться тому факту, что в мире куча разных компаний шьют одежду, выпускают автомобили, телефоны, запускают почтовые сервисы…
Размещаем в Амазоне наш сервис Битрикс24 — социальный интранет, SaaS-сервис, объединяющий в себе классические инструменты командной работы (календари, задачи, CRM, работа с документами) и социальные коммуникации («лайки», социальный поиск, мгновенные сообщения).
Активно используем связку ELB + AutoScaling + CloudWatch. S3 — для хранения данных. Снэпшоты для бэкапов.
Серьезные крупные приложения под высокой нагрузкой все равно потребуют того или иного тюнинга для конкретных условий (объем данных, характер запросов и т.п.)
FLUSH QUERY CACHE — да, полезно. Только очень аккуратно и не в пиках нагрузки.
Один раз поймали зависание в момент выполнения FLUSH QUERY CACHE.
> В версии 5.5 есть опция innodb_force_load_corrupted
О. Отлично!
Видимо, стартовавшая сегодня акция? www.1c-bitrix.ru/about/life/news/486531/ (сорри за оффтопик...)
Многое действительно не описали подробно, а лишь «задали направление», так как при детальном описании получится не статья на Хабр, а книга High Performance MySQL. :)
Все-таки рассчитываем не на cut-n-paste конфигов, а на более детальное изучение.
Наверное, попробую собраться с мыслями и написать в ближайшее время. :)
Если не будет индексов (зачастую — составных, которые надо построить самим), то он, видимо, всегда так будет рапортовать. :)
И «join_buffer_size = 8G» — это в любом случае плохо. Вот неплохое описание (с комментариями), как происходит выделение памяти для join_buffer_size:
www.mysqlperformanceblog.com/2010/07/05/how-is-join_buffer_size-allocated/
И сколько у вас было при этом RAM в системе?
Эта статья — о практиках использования MySQL. Для любых проектов, на Битриксе они сделаны или нет.
Если вы как на красную тряпку реагируете именно на слово «битрикс», тут уж ничего не поделаешь — так уж сложилось, что в данном случае практическим опытом делимся именно мы. И очень верю, что для многих он — полезен.
В противном случае «м-м» в принципе не будет работать.
Но даже с настроенными auto_increment_increment и auto_increment_offset «Duplicate entry» все равно будут. Один из возможных сценариев появления такой ошибки как раз описан в статье.
— xtrabackup тоже используем, но для других сценариев. Снэпшот и образ машины делаются сильно проще и быстрее. Да и разворачивать их потом тоже легче.
marketplace.1c-bitrix.ru/solutions/citrus.ace/
marketplace.1c-bitrix.ru/solutions/cn.highlight/
Спасибо за добрые пожелания! ;)
Видео — тоже будет.
Но если кто-то говорит «тормозит» — без указания, что именно, проще, наверное, спросить, чем выступать в роли ясновидцев?
Если серьезно — все разные по функционалы. Да, конечно, так или иначе пересекаются многие. Но у всех своя «фишка».
Далее — важна конкуренция. Она очень хорошо стимулирует на развитие. Вы же вряд ли будете возмущаться тому факту, что в мире куча разных компаний шьют одежду, выпускают автомобили, телефоны, запускают почтовые сервисы…