Нестандартные блокировки при работе с OLAP-нагрузкой

Публикация № 1267307

Администрирование - Производительность и оптимизация (HighLoad)

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

Добрый день, уважаемые коллеги! Наш доклад будет посвящен теме производительности. Для начала мы представимся – Станислав Щербаков, ведущий программист компании «Петрович» и Александр Денисов, специалист по производительности компании «СофтПоинт».

 

Про «Петрович»

 

 

Станислав Щербаков: Сначала я расскажу пару слов о нашей компании, и о том, как наша деятельность связана с производительностью.

«Петрович» – это одна из крупнейших DIY-сетей в России. DIY – это известное английское сокращение Do It Yourself, соответственно, это крупная сеть гипермаркетов строительных товаров – товаров для стройки и ремонта. Наш оборот почти 50 млрд рублей в год (примечание: финансовые показатели, указанные в докладе, актуальны на момент выступления — сентябрь 2019).

 

 

Компания появилась в 1995 году. Сейчас у нас уже 19 магазинов и более 6 тысяч сотрудников. В день происходит порядка 20 тысяч отгрузок – каждые 4-5 секунд происходит одна отгрузка.

 

 

Из всех этих отгрузок порядка 40% проходит через наш сайт https://petrovich.ru/

 

 

Теперь немного расскажу про технологический стек, и подойдем уже к нашей основной теме.

  • Все наши ИТ-системы интегрируются через шину. В качестве шины мы используем продукт MuleESB – это продукт, написанный на Java с использованием Spring. Он проповедует событийную модель. Грубо говоря, когда в любой системе происходит событие, она оповещает об этом шину, а шина оповещает все подписанные на это событие системы. Например, мы ведем справочник «Номенклатура» в отдельной 1С-ной базе. Если в какой-то элемент вносятся изменения – номенклатура записывается, зарегистрируется, сигнал об этом передается шине, а шина уже отдает сигнал всем, кто подписан, чтобы они забрали измененную номенклатуру.
  • Пару слов про сайт. Backend сайта написан на PHP7, база на MySQL и PostgreSQL. Кроме этого мы используем Kafka, Redis и Elasticsearch. А frontend написан на TypeScript и React.
  • Пару лет назад у нас появилась Big data, соответственно, мы используем дистрибутив Hortonworks.
  • Большая часть нашей внутренней инфраструктуры обеспечивается программистами 1С – соответственно, у нас порядка 30 больших production-баз, самая огромная из которых весит более 7 Тб. Мы следим за здоровьем всех этих систем, собираем в Zabbix все показатели производительности, все данные о функционировании систем.

Про сами системы можно очень долго рассказывать, потому что есть еще WMS-системы и специализированные решения для торгового оборудования. Но перейдем уже непосредственно к теме производительности.

Так как у нас большие 1С-ные базы, которые используют Microsoft SQL, значит, нам часто приходится решать задачи, связанные с оптимизацией производительности. Об одной из них мы сегодня расскажем более подробно.

 

Про ГК «СофтПоинт»

 

 

Александр Денисов: Теперь пару слов о компании Софтпоинт и о том, как я вообще оказался на этой сцене.

Мы в компании Софтпоинт почти 15 лет занимаемся производительностью, помогаем нашим партнерам и коллегам выжимать максимум из их баз данных, заставляя их работать на максимально возможном пределе. С компанией «Петрович» в формате поддержки мы работаем уже 5 лет – следим за их системами в ежедневном режиме и даем какие-то оперативные рекомендации, если видим, что что-то можно улучшить, подкрутить. И иногда по их просьбе привлекаемся как приглашенные эксперты при расследовании каких-то сложных случаев. Об одном из таких случаев мы сегодня и расскажем.

 

Запуск отчета вызвал неожиданные «тормоза» по всей базе

 

 

Станислав Щербаков: Однажды к нам в техподдержку обратились с проблемой производительности, когда отчет вызывал «тормоза» по всей 1С-ной базе. Причем, эта 1С-ная база не очень большая – 1.5Тб в размере. В этой базе мы ведем оперативный учет всех подразделений Санкт-Петербурга, она работает 24/7.

Соответственно, мы начали проблему декомпозировать, разбирать дальше.

Сам отчет был построен на СКД, мы стали смотреть его запрос – подумали, что сейчас разберем его, найдем «узкие места», оптимизируем, и золотой ключик будет у нас в кармане.

 

Анализ плана медленного запроса

 

 

Мы стали смотреть на план запроса и увидели, что какой-то одной большой операции, которая бы отнимала больше 50% от всего, у нас нет. Время выполнения у нас поделилось между тремя большими операциями – Index Scan, Index Seek и Compute Scalar.

 

 

SQL не дает каких-то подсказок по неиспользуемым индексам.

 

 

Одну подсказку все-таки нашли – в описании Index Scan видно, что записей получается в 100 раз меньше, чем фактически произведенного чтения. Вот одно из мест, где у нас скрылась неоптимальность.

 

 

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

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

Обратим внимание на приведение к типу – у нас есть ресурс составного типа, поэтому в соединении используется ВЫРАЗИТЬ. Это – ключ к тому, почему была проблема. Добавлю, что по нашему ресурсу у нас есть индекс. Дальше разберем, почему он не используется и что здесь происходит.

 

 

Сверху – вариант неоптимального запроса, как он был только что представлен в конструкции ВЫРАЗИТЬ. У нас на SQL ВЫРАЗИТЬ превращается в CASE для явного приведения к типу. И эта конструкция уже не дает использовать индекс.

Давайте поговорим, почему это происходит.

Функция CASE оборачивает наши поля, которые покрыты индексом, и можно провести хорошую аналогию с книгой и с оглавлением. Допустим, если мы хотим найти конкретную главу и знаем ее точное название целиком, то по названию и оглавлению мы быстро ее находим. Но если мы знаем только то, что у нас третья буква слева – это «г», то найти нам будет уже намного проблематичнее. Придется просканировать все оглавление, и только тогда мы сможем понять, какие нам нужны главы.

Такая же история и внутри SQL-сервера. В данном случае, когда мы применяем функцию CASE к полям, даже покрытым индексом, индекс полноценно не используется. Такая же штука может произойти и с другими функциями. Например, DATEADD (ДОБАВИТЬКДАТЕ), любые арифметические операции в запросе и т.д.

Важно отметить, что здесь мы использовали ВЫРАЗИТЬ именно внутри соединения. Мы все видели рекомендации на ИТС про необходимость приведения к типам при получении данных в полях, но эти рекомендации нужно читать внимательно – к соединениям и к условиям это никоим образом не относится. Там, получается, что применять ВЫРАЗИТЬ нельзя.

 

 

Что у нас получилось после того, как мы убрали ВЫРАЗИТЬ? Получилось, что запрос у нас ускорился в 8 раз.

 

 

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

Действительно, теперь в плане есть Index Seek.

 

 

И в предикатах видим наш ресурс _Fld19171, который теперь используется.

 

 

Замечательно. Запрос оптимизировали, казалось бы, сейчас отчет будет быстрее выполняться, жалобы должны уйти. Но почему-то жалобы остались. Плюс, как мы говорили, отчет влиял еще и на другие системы – и вызывал «тормоза» по всей базе. Тут мы попросили помочь с расследованием коллег из Софтпоинта.

 

Нестандартные ожидания на блокировках

 

Александр Денисов: Нас периодически привлекают, как приглашенных экспертов для расследования каких-то сложных случаев. И этот случай действительно оказался сложнее, чем виделось в самом начале. Казалось бы, тормозит обычный отчет – один пользователь ждет, пока он выполнится, ну и пускай подождет. Отчеты в 1С по своей сути не могут заблокировать других пользователей. Но в этот раз почему-то вместе с отчетом ждали и другие пользователи базы данных.

 

 

Первым делом, когда поступила заявка, мы начали с того, что просто посмотрели – что происходит на сервере в момент выполнения отчета?

На рисунке выше показаны SQL-сессии в момент инцидента. Видно, как они выполняются, какие ожидания и т.д.

Картина оказалась довольно неожиданной. В самом топе по нагрузке на CPU, как мы и ожидали увидеть, наша сессия с отчетом – видно, что 99% процессора съедено, он что-то считает, что-то выполняет – ничего необычного.

 

 

Но под этим отчетом у нас собирается очередь ожидания. Казалось бы, это – нормальный, обычный отчет. Все знают, что в 1С отчеты выполняются в режиме NOLOCK, т.е. с грязным чтением. Они по определению сами игнорируют наложенные блокировки и никого не ждут – и в то же время не накладывают собственных блокировок и никого не могут подвесить. А здесь вместо этого какая-то небывальщина и выглядит странно.

 

 

Продолжили разбираться дальше. Если посмотреть внимательнее, видно, что все сессии висят не на нашей 461-й сессии, а на сессии уровнем ниже – с номером 30. Какая-то непонятная сессия, тип ожидания у нее еще SCH M (Schema Modification) – его видно в самой правой колонке.

Если бы у нас было какое-то обычное ожидание, как при проведении документа или изменении данных, мы бы не удивлялись, что оно «подвешивает» всех остальных.

Как это обычно выглядит? В колонке с типом ожидания будет либо U-блокировка (блокировка на Update), либо X-блокировка (эксклюзивная блокировка на данных). Все понятно, все логично.

Вместо этого у нас здесьблокировка модификации схемы. Кто-то просто в разгаре рабочего утра, в 8:42, не моргнув глазом, меняет схему. А схему в 1С мы можем поменять одним легальным способом - сделав реструктуризацию ИБ из конфигуратора, что никак не совмещается со 100 активными пользователями.

Смотрим дальше – в ресурсе блокировки у нас ключевое слово STATS (статистики). И с этого момента становится более-менее понятно, что вообще здесь происходит.

 

Небольшое отступление. Что такое статистика?

 

 

Небольшое отступление. Поговорим немного про то, что вообще такое статистики, и зачем они нужны. Разберем эту тему чуть подробнее.

 

 

Говоря про то, зачем нужны статистики, я буду говорить про MS SQL Sever, но на самом деле, в PostgreSQL это тоже примерно так же работает, с небольшими изменениями.

Так вот – все мы сегодня слышали уже в предыдущих докладах, что язык SQL у нас декларативный, он говорит, что нужно получить.

При этом как СУБД будет получать эти данные – она решает сама. Конечный способ получения и обработки данных описывается в плане запросов. План – это пошаговая инструкция, куда посмотреть, что сделать, с чем объединить. Повторюсь, СУБД строит этот план самостоятельно.

И когда СУБД строит план запроса, ей нужно сделать какие-то решения. Например, у нас есть три классических способа соединения данных:

  •  Nested loops – вложенные циклы;
  •  Hash math;
  •  И Merge Join

У каждого из них есть свои плюсы и минусы.

  • Кто-то хорошо работает на больших массивах данных, когда и слева, и справа у нас большие объемы. Но зато требует много ресурсов, много оперативки.
  • Кто-то, наоборот, хорошо работает на маленьких объемах, работает очень экономно, но зато проседает на больших объемах.

И в итоге эффективный выбор нужного оператора – это очень большая проблема. Я в своей практике видел сотни раз, когда из-за ошибки оптимизатора, который выбирает неправильный вариант соединения данных, запрос проседает в сотни раз (было полминуты, получилось 10 минут) – из-за того, что выбрался Nested loops, когда не надо было или наоборот.

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

Нам нужно знать, сколько у нас данных будет в каждой из соединяемых сторон. Как у нас сервер может это узнать? Тут у нас как раз включается статистика.

 

 

Статистика – это специальный объект в базе данных. Если вы раскроете в Object Explorer объекты, которые у вас есть, у вас будут таблицы, индексы и отдельно будет папка «статистики».

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

Соответственно, статистика нужна, чтобы SQL Server знал, сколько ему строк вернется.

Он спрашивает: «Сколько у нас Ивановых в базе данных?» И статистика ему отвечает: «Ивановых у нас 10 тысяч».

«А Бахрушиных сколько будет?» – «Примерно пять человек».

Там, конечно же, не для каждого целые числа, но примерные значения мы получаем.

 

 

Сервер SQL спрашивает у статистики, сколько ему вернется строк, статистика ему отвечает.

 

 

Сервер SQL после этого решает, что в этом конкретном случае поможет Hash math, и выбирает правильный план. Все здорово, пользователь получает быстрый результат запроса, DBA радуется, что у нас экономятся ресурсы. Все счастливы и довольны.

Но должна же быть какая-то ложка дегтя.

Конечно, она есть. Дело в том, что статистики в SQL-сервере не обновляются с изменением данных. Данные меняются, а статистика остается на каком-то заранее посчитанном уровне.

Чем дольше мы работаем без пересчета статистики, тем быстрее они перестают отвечать актуальным данным. Они возвращают те же самые значения, которые совершенно не попадают в реальное распределение.

Соответственно, оптимизатор начинает ошибаться, и мы получаем неправильный, неэффективный план.

 

 

Статистики нужно обновлять. Как мы можем это сделать?

У нас есть три варианта:

  • Либо мы вручную запускаем UPDATE STATISTIC. Есть специальная команда в Management Studio – выполняем обновление статистик, все пересчитывается.
  • Второй вариант – мы делаем регулярное перестроение индекса (REBUILD). Вместе с этим соответствующая статистика тоже пересчитается.
  • И есть третий вариант, для ленивых администраторов. Есть специальный процесс, который называется автоапдейт статистик. Это – специальный компонент, который сидит в памяти и следит за состоянием всех статистик в вашей базе данных. При превышении какого-то порога он решает что уже пора, хватит это терпеть, статистику нужно пересчитать, и он ее обновляет.

 

 

Отлично, обновили знания, возвращаемся обратно.

 

Активность проблемной сессии

 

 

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

Соответственно, в той ситуации, которую мы видим на скриншоте, как раз этот автоапдейт статистик и сработал.

Смотрите сами:

  • у нас есть тяжелый запрос, который что-то выполняет, читает очень много данных, которому явно нужно знать распределение данных для того, чтобы построить план.
  • У нас есть под ним какая-то странная сессия с номером подключения 30. Надо знать, что все подключения SQL сервера с номерами до 50 – это, как правило, служебные подключения. На них ни администратор, ни пользователь повлиять не могут. Они появляются сами собой, сами собой закрываются и делают все, что хотят.
  • У нас есть ожидания на модификации схемы – как я уже говорил, статистика физически хранится в схеме (это реальный объект схемы).
  • И у нас есть ожидания – блокировки на чтении схемы, которые ждут, когда уже изменение закончится и все стабилизируется.

Получается, что этот наш проблемный запрос начал выполняться, увидел, что статистика устарела, запустил дочерний процесс пересчета статистик и продолжил выполнять свой запрос.

Перестроение статистик перечитало таблицу, подготовило новую статистику и готово уже подменить старую статистику на новую, заменить ее. Все классно, но для того, чтобы подменить статистику, нам нужно дождаться, пока закончатся все запросы, которые работают с этим объектом. А такой запрос как раз есть – это наш исходный тяжелый запрос.

Получается, что этот дочерний процесс ждет, пока закончится долгий запрос и держит блокировку схемы.

 

 

В это время появляются другие запросы, которые говорят: «У нас устарела статистика, куда нам посмотреть». И вот эта 30-тая версия говорит: «Сейчас у нас статистика будет, подождите, я ее поменяю». И получается, что весь этот паровоз ждет, пока долгий запрос окончательно не сформируется. Очень неочевидная история. Получается, что отчет, который выполняется без транзакции с NOLOCK, все равно собрал после себя какое-то большое дерево ожидания.

 

Факторы риска

 

 

Какие факторы риска для того, чтобы это произошло?

  • Во-первых, это должны быть достаточно большие таблицы, чтобы они долго пересчитывались, чтобы этот процесс пересчета статистик занял какое-то время, и мы это заметили.
  • Дальше – чем реже у вас пересчитываются статистики, тем больше вероятность, что у вас автоапдейт статистик сработает. Если вы сами не занимаетесь этой работой, то кто-то займется ею за вас.
  • И третье, что здесь сыграло ключевую роль – это то, что в OLTP-системе выполняются долгие OLAP-запросы. Это – неудивительная история для 1С, она тем и славится, что у нее и OLTP, и OLAP-нагрузка выполняются.

Почему это важно, почему это «выстрелило»?

 

 

Вернемся назад. Вот наша 30-я сессия, которая «висит». Если бы у нас 461-я сессия проводила какой-то короткий документ, то 5 секунд ожидания – ерунда, никто бы не заметил.

Вся проблема в том, что этот блокирующий запрос выполнялся долго. Именно поэтому мы эти блокировки и заметили.

Чтобы не попасть в такую ситуацию, нужно следить за статистиками, если есть возможность, выносить аналитику на какие-то дополнительные сервера или ноды.

 

Решение проблемы

 

 

Как мы в данном случае решили эту проблему?

Мы просто отключили автообновление статистик. Звучит довольно страшно, потому что статистики нужны. Но дело в том, что мы сделали регулярное задание пересчета статистик.

Получилось, что, с одной стороны, каждую ночь у нас пересчитываются статистики – мы знаем, когда это происходит.

С другой стороны, для нас в этой ситуации автоапдейт статистик работал как мина замедленного действия. Совершенно непонятно, когда она сработает и в какой момент. Это будет, скорее всего, для нас неожиданно и неудобно.

Поэтому мы эту неожиданную плавающую проблему просто отключили. И возложили проблему пересчета статистики на наши плечи и сами с ней эффективно справляемся.

После этого поведение системы стало более стабильным. Мы теперь знаем, когда нам ждать блокировок, когда их не ждать, и все это теперь отлично работает.

 

Выводы

 

Какие выводы из всей этой ситуации

  • Мы начали с оптимизации 1С-ного запроса, причем, увидели, как простая конструкция приведения к типу (ВЫРАЗИТЬ), но примененная в соединении (такая же ситуация могла случиться, если бы она была в условиях), у нас испортила весь запрос. Не только не улучшила, уменьшив выборку, но и ухудшила ситуацию. Здесь нужно понимать, что к рекомендациям нужно относиться внимательно, рекомендации относительно ВЫРАЗИТЬ в запросах есть только относительно полей самого запроса.
  • Да, а на стороне сервера SQL получилось так, что инструмент, который призван облегчать жизнь администратору и программисту, а он, наоборот, ее усложнил. Тут тоже нужно помнить, что любые облегчающие вещи работают в 90% случаев, но везде есть какие-то «дыры» в абстракциях, какие-то исключения. Просто нужно про это помнить, не забывать. И не полагаться вслепую на какие-то автоматические вещи. Думать головой.

 

Вопросы:

 

  • Как правильно – одно задание на асинхронный и автоматический пересчет статистики или вообще ни одного задания не использовать?
  • Есть такой знаменитый американский SQL-блогер Пол Рэндалл - он еще был среди авторов первых версий SQL Server. Он любит на такие вопросы отвечать: «in depends». Все всегда зависит от ситуации. На самом деле есть много факторов. Все зависит от базы, от нагрузки и т.д. Если у вас есть регламентное окно каждую ночь – круто. Вы каждую ночь просто пересчитываете статистики и индексы. Лучше статистику пересчитывать, когда в базе никто не работает. Если у вас вообще никакого времени для технологического окна никогда нет, и у вас есть выбор, что делать (это вообще-то и есть Highload), то приоритет должен быть у статистик. Потому что если мы перестраиваем индексы, делаем Rebuild, они лежат на диске лучше, мы читаем чуть поменьше. Но с нашими скоростями дисков – это не такой большой выигрыш. Если же мы перестраиваем статистики, они влияют на качество ваших планов, насколько эффективно работает ваш запрос. Это – то, за что стоит бороться. Поэтому, если есть выбор, предпочтение нужно отдавать в пользу статистик. Более того, есть разные таблицы, с которыми мы работаем с разной интенсивностью, и если у вас есть DBA или эксперт по техвопросам, то, наверное, автоматическое асинхронное обновление статистики нужно выключать. Надо оставлять выборочно: по этой таблице – раз в час обновляем, по этой таблице – раз в день, а эту вообще можно не пересчитывать.
  • Возвращаясь к пересчету статистики – если делать пересчет статистики во время работы, не в ночное окно, вы же процедурный кэш тоже сбрасываете? Как вы решаете эту проблему?
  • Он сам сбрасывается. При пересчете статистик все планы, которые основывались на этой статистике, сразу помечаются, как устаревшие. Они не удаляются сразу, вы можете их в кэше увидеть, но на них ставится флаг, что они устаревшие. И при следующем обращении к этому плану он будет автоматически перекомпилирован. Если вы не доверяете этому механизму, если у вас маленький кэш, если у вас небольшая нагрузка, можно вручную сбрасывать. Если у вас большая система, я бы этот кэш пожалел, потому что он уже наработан кровью и потом ваших пользователей – сбрасывать просто так его не стоит.
  • Я про то, что фирма «1С» рекомендует после обновления статистик делать сбрасывание кэша командой DBCC FREEPROCCACHE.
  • Здесь фирма «1С» скорее перестраховывается. Знаете, в математике есть «необходимое» и «достаточное». У 1С рекомендации достаточные – чтобы все работало всегда, в любых условиях, без шанса на сбой в каких-то экзотических окружениях. И иногда такая перестраховка оказывается избыточной. Вы-то свои условия знаете. Вы можете убедиться, что при пересчете статистик планы обновляются. Соответственно, можете сами принять решение.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. TMV 14 23.07.20 10:42 Сейчас в теме
Вопрос по запросу: Соединение справочника со срезом регистра сведений по ссылке справочника и полю регистра - зачем вообще преобразовывать/проверять тип поля регистра? Соединение всегда будет Ложь, если тип не такой.
Изначальное отсутствие этой ошибки в запросе привело бы к отсрочке проблемы со статистикой и отсутствию это доклада)
2. Филин 141 24.07.20 00:00 Сейчас в теме
(1)
Вопрос по запросу: Соединение справочника со срезом регистра сведений по ссылке справочника и полю регистра - зачем вообще преобразовывать/проверять тип поля регистра? Соединение всегда будет Ложь, если тип не такой.


Преобразование было добавлено потому что "перебдели" с гайдлайнами - как в докладе и сказали. 1С пишет "добавляйте ВЫРАЗИТЬ" - ну его, неподумав, и добавили. В общем-то смысл этой части доклада и был про то, что читать "best practice" нужно вдумчиво и понимать, где это нужно, а где нет.

Статистика на таких объёмах всё равно бы выстрелила (и, в общем, стреляла уже несколько раз). Ну да, рассказали бы про неё не в 19 году, а чуть попозже )
4. Cyberhawk 122 02.08.20 12:59 Сейчас в теме
(2)
читать "best practice" нужно вдумчиво и понимать, где это нужно, а где нет
Можно цитату того фрагмента из "гайдлайна", который после "вдумчивого понимания" применять оказалось не нужно?
5. Филин 141 02.08.20 15:59 Сейчас в теме
(4) Гм, ну вот в самом конце доклада (последние 2 вопроса из зала) обсуждается рекомендация: "очищать процедурный кэш после пересчета статистик" при помощи DBCC FREEPCOCCACHE. Сама рекомендация от 1С приведена на ИТС в документе " Регламентные операции на уровне СУБД для MS SQL Server "

Или вот рекомендация выключить параллельное выполнение запросов (maxDOP = 1), примерно оттуда же. Да в спорах, о значении этой опции сломано много копий, но после вдумчивого понимания конкретного контекста я часто рекомендую значения больше 1
6. Cyberhawk 122 02.08.20 17:45 Сейчас в теме
(5) Я, наверное, неточно задал вопрос - имел в виду про "ВЫРАЗИТЬ".
Я просто не встречал от вендора рекомендации использовать это в условиях соединений, поэтому и совет "вдумчиво понимать, где это нужно, а где нет" тут не кажется применимым, т.к. прочитать про такое возможности изначально у читателя нет.
Поэтому, наверное, больше подошел бы совет читателю просто внимательнее читать. А то получился незаслуженный камень в огород 1С :)

Про очистку процедурного кэша скорее согласен (на ИТС также остались и иные рекомендации касательно СУБД, уже устаревшие - например, флаги трассировок и некоторых настроек СУБД, которые начиная с ~2014-2016 версий скуля уже перенесены в коробку, т.е.включены по умолчанию), но с моей позиции "любителя" остается момент с тем, что кэш без очистки остается все-таки наполненным, пусть и с пометкой неактуальности, что в дальнейшем несет какой-то оверхед (по сравнению с тем, если бы он стал пустым).

Про MaxDoP кажется, что лучше и не начинать :)
7. Филин 141 03.08.20 11:17 Сейчас в теме
(6)Про "ВЫРАЗИТЬ" - это случай, когда надо "читать рекомендации внимательно". Станислав еще в докладе указал, что 1С нигде не рекомендует использовать Выразить в условиях соединения. Это программист прочитал рекомендацию не сильно вчитываясь и применил ее там, где не нужно было.

Так что здесь история не про плохую рекомендацию, а про торопливого программиста.
Дмитрий74Чел; +1 Ответить
8. Дмитрий74Чел 196 28.08.20 16:03 Сейчас в теме
Картинки с сессиями sql - не из SqlMangementStudio. Полагаю, разработка softpoint. А в studio можно как-то такой же отчет получить?
Оставьте свое сообщение

См. также

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    29557    MrWonder    42    

Описание почти всех событий технологического журнала

Технологический журнал v8 Бесплатно (free)

Краткое описание событий технологического журнала с примерами. Все для быстрого старта.

19.08.2020    5272    YPermitin    22    

Адаптация автоматической классификации ошибок технологического журнала при появлении новых текстов и типов

Технологический журнал v8 1cv8.cf Бесплатно (free)

Корректируем классификацию ошибок ТЖ в процессе работы для конфигурации мониторинг производительности

17.08.2020    356    ivanov660    0    

SQL для 1С: пишем правильно, красиво, сложно

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Многие программисты боятся работать с Null, считая, что от этих данных в запросах нужно избавляться. О том, как с помощью Null-полей в запросе решать востребованные в учете задачи по выборке данных, на конференции Infostart Event 2019 Inception рассказал ведущий разработчик ГК WiseAdvice Дмитрий Дудин.

14.08.2020    8757    dmurk    30    

Долго открывается конфигуратор Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    40865    Gilev.Vyacheslav    1    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

В статье обсудим пример практической настройки конфигурации «Мониторинг производительности» для автоматической классификации ошибок по группам/кластерам на данных текстов описания ошибок. Используем механизм векторной модели текстов и косинусное сходство между ними.

25.06.2020    2638    ivanov660    12    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

Обычно предметом оптимизации являются заранее определенные ключевые операции, т.е. действия, время выполнения которых значимо для пользователей. Причиной недостаточно быстрого выполнения ключевых операций может быть неоптимальный код, неоптимальные запросы либо же проблемы параллельности. Если выясняется, что основная доля времени выполнения ключевой операции приходится на запросы, то осуществляется оптимизация этих запросов. При высоких нагрузках на сервер СУБД в оптимизации нуждаются и те запросы, которые потребляют наибольшие ресурсы. Такие запросы не обязательно связаны с ключевыми операциями и заранее неизвестны. Но их также легко выявить и определить контекст их выполнения, чтобы оптимизировать стандартными методами.

24.05.2020    7206    DataReducer    22    

[SQL Server] Использование trace flag 9592 для сжатия траффика в кластере AlwaysOn

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Недавно мы столкнулись с проблемой производительности, при которой дополнительная нагрузка, связанная с записью большого массива данных, приводила к существенным задержкам в операциях записи основного траффика. Найденное решение позволило не только уменьшить влияние нового процесса на основной пользовательский трафик, но и существенно снизить сетевой траффик между синхронными репликами кластера.

18.05.2020    2037    Aleksey.Bochkov    3    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    67231    yuraos    112    

Эти занимательные временные таблицы

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    11448    YPermitin    0    

Оптимизация запросов 1С посредством индексации временных таблиц. Миф? Тестируем, смотрим, считаем

Производительность и оптимизация (HighLoad) Практика программирования v8 Бесплатно (free)

Появилось свободное время, решил проверить на работе индексацию таблиц. Решил поделиться с Вами результатами исследования. Давайте порассуждаем на эту тему? Часто ли вы пользуетесь индексацией в запросах? Платформа 8.3.16.1224

03.04.2020    4155    feva    15    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    12629    informa1555    31    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

Не секрет, что многие пользователи, использующие партионный учет (а таких очень много, даже среди огромных холдингов, несмотря на пропаганду РАУЗ) при больших нагрузках сталкиваются с резким замедлением списания партий.

21.06.2013    54327    Антон Ширяев    117    

Многострочный контекст событий

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

Разбор технологического журнала с группировкой событий по первой или последней строке многострочного контекста.

31.03.2020    3109    vasilev2015    9    

Анализ взаимоблокировок

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

Скрипт Bash, который выводит полную информацию взаимоблокировок по технологическому журналу. Не имеет аналогов в отечественных публикациях.

20.03.2020    4762    vasilev2015    24    

Многопоточность

Практика программирования Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    7067    kaliuzhnyi    43    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    54702    Gilev.Vyacheslav    46    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    9409    Evil Beaver    13    

Оптимизатор запросов. Вторая часть

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Продолжение статьи об оптимизаторе запросов. Во второй части мы попробуем создать свой оптимизатор и попутно разберемся с такими вопросами, как: хранение файлов; индексы; статистика.

23.01.2020    6384    darkdan77    59    

Параллельные вычисления в 1С 8 Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    30041    gallam99    19    

Улучшаем производительность 1С. Рекомендации

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Каждый уважаемый разработчик 1С сталкивался или столкнется с вопросом производительности высоконагруженных систем. В статье агрегирован основной набор рекомендаций, который позволит повысить производительность системы. Эти рекомендации должны быть просто must have по определению.

23.01.2020    7759    Kaval88    26    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    11181    ivanov660    16    

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    7544    EugeneSemyonov    11    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    42242    madmpro    32    

Обслуживание баз данных. Не так просто, как кажется

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    17611    YPermitin    28    

Мониторинг высоконагруженной системы

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    8962    Repich    5    

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Администрирование данных 1С Zabbix v8 Бесплатно (free)

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    18513    Sloth    24    

Хранение файлов - как уменьшить размер базы данных

Чистка базы Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 Россия Бесплатно (free)

Хранение файлов в базе 1С можно оптимизировать для уменьшения размера хранимых данных.

09.09.2019    8492    2tvad    17    

Неочевидные проблемы производительности: важность системного подхода при анализе

Производительность и оптимизация (HighLoad) v8 Россия Бесплатно (free)

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    8913    Филин    12    

Ловля блокировок на связке "Microsoft SQL server - 1С"

Производительность и оптимизация (HighLoad) v8 v8::blocking Бесплатно (free)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    9886    fhqhelp    0    

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным

Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка v8 Бесплатно (free)

В этой статье приведен пример неочевидной "оптимизации" запроса, которая противоречит всем правилам, описанным в книгах для подготовки к сертификации "1С:Эксперт по технологическим вопросам", а также преподаваемым на курсах подготовки экспертов.

02.07.2019    11287    igordynets    119    

Ускорение чтения правил обмена в УПП 1.3 в 20 раз!

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

27.06.2019    9807    YPermitin    17    

Хотите снизить нагрузку на процессор сервера в 2 раза?

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

В статье рассмотрено влияние частого запуска регламентных заданий на процессор сервера 1С.

27.06.2019    9611    Дмитрий74Чел    6    

Непридуманные истории по оптимизации. История 1

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    12621    Repich    117    

Оптимизация: неэффективные запросы

Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

В большинстве случаев основной причиной медленной работы системы при многопользовательском режиме работы является блокировка данных СУБД (говорим про клиент-серверную версию). Блокировка - это не есть хорошо или плохо, это жизненно необходимая вещь при построении прикладной логики работы системы. Но блокировки таблиц, записей могут быть как вполне законными, так и далеко не всегда оправданными в каждой конкретной ситуации. Одной из самых распространенных причин неоптимальной блокировки ресурсов является некорректное написание запросов.

13.06.2019    5884    slayer-ekb    10    

Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

Практика программирования Производительность и оптимизация (HighLoad) v8 v8::Запросы Бесплатно (free)

Взаимодействие с Microsoft SQL Server нередко вызывает трудности у 1С-ников, а потому интересны любые моменты, связанные с его использованием. О своем опыте работы с новым SQL Server 2017 участникам конференции Infostart-2018 рассказал директор ООО «Аналитика софт» Дмитрий Дудин.

11.06.2019    24976    dmurk    145    

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    19099    ivanov660    9    

Не думать о секундах свысока...

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    7942    vasilev2015    21    

Альтернативная стратегия управления блокировками

Производительность и оптимизация (HighLoad) v8 v8::blocking 1cv8.cf Россия Бесплатно (free)

Данная публикация освещает одну из альтернативных стратегий блокирования данных на уровне MS SQL Server, которая недоступна средствами 1С, но может быть весьма полезной. Разбирается практический пример.

20.05.2019    7158    zhichkin    15    

Как работают управляемые блокировки

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Все типовые конфигурации содержат ошибки, потому как управляемые блокировки в 1С слишком уж "управляемые", при понижении уровня изоляции про некоторые "нюансы" просто забыли. Для создания и эксплуатации качественной системы, которая способна поддерживать транзакционную целостность данных при параллельной работе, информацию в этой статье желательно знать, хотя, конечно, ничего особо нового я не открыл.

29.04.2019    22945    comol    198    

Странное потребление места на диске С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    14167    kuzyara    12    

Включение встроенного в платформу механизма "Копии базы данных" и использование "Дата Акселератора". Новый стандартный механизм использования баз OLAP в 1С

Производительность и оптимизация (HighLoad) v8 Россия Бесплатно (free)

С версии 1С 8.3.14 в платформе появился новый функционал «Копии базы данных». В данной публикации я хочу рассказать, как включить использование данного механизма в платформе 1с и как его использовать для получения отчетов с копии базы данных, которая может быть вынесена на внешний сервер относительно текущей базы данных, а также как использовать систему «Дата акселератор», в которой база данных целиком размещена в оперативной памяти рабочего сервера кластера серверов «1С:Предприятия».

25.04.2019    14119    Elf1k    27    

5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

В этой статье мы разберем механизм использования конфигурации "Анализ технологического журнала" на практике, и всего через 15 минут работы вы получите функциональный, удобный инструмент мониторинга проблем производительности базы 1С.

18.04.2019    29758    ivanov660    77    

Как разбить базу на файлы и не сойти с ума

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Разбиение базы данных 1C на файлы и последующее сопровождение. Нюансы, грабли и прочее.

06.04.2019    15892    YPermitin    30    

Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

В связи с санкциями и другими событиями сейчас все более и более актуальна тема перевода ПО компаний на отечественное и свободное программное обеспечение. Одной из самых востребанных СУБД на рынке на данный момент является PostgreSQL - надежная, высокопроизводительная и хорошо масштабируемая СУБД, которая является прямым конкуретном таким крупным компаниям с их топовыми продуктами, как Oracle, IBM и Microsoft. Однако каждый, кто переходит на PostgreSQL, сталкивается с трудностями, прежде всего с настройкой и производительностью. Не обошли проблемы с производительностью "слоника" и меня. Предлагаю вашему вниманию перевод статьи "How a single PostgreSQL config change improved slow query performance by 50x" автора Pavan Patibandla, которая мне помогла улучшить производительность PostgreSQL.

18.03.2019    15852    w.r.    23