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

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

Администрирование БД - 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. Филин 185 24.07.20 00:00 Сейчас в теме
(1)
Вопрос по запросу: Соединение справочника со срезом регистра сведений по ссылке справочника и полю регистра - зачем вообще преобразовывать/проверять тип поля регистра? Соединение всегда будет Ложь, если тип не такой.


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

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

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

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

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

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

См. также

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

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

22.04.2015    46702    Gilev.Vyacheslav    1    

Нагрузочное тестирование в 1С:ERP

HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

02.11.2022    2299    Tavalik    23    

Тормоза при записи номенклатуры в ERP 2.5.8.287

HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

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

25.10.2022    532    m191    6    

Как я Java учил, а потом 1С-у удивлялся

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Сравнение производительности 1С с Java.

23.09.2022    1802    Hadgehogs    23    

Видеодемонстрация применения Теста-центра для нагрузочного тестирования конфигураций Промо

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

16.09.2012    37169    Aleksey.Bochkov    29    

Партицированная дисциплина программиста в 1С

HighLoad оптимизация Механизмы платформы 1С Запросы Платформа 1С v8.3 Бесплатно (free)

Почему при росте объемов базы 1С все становится медленней, даже если все индексы правильно сделаны? В статье на простом примере с регистром сведений показана причина и как этого избежать. Кто виноват больше, 1С или MS SQL решать Вам :)

20.09.2022    1392    1CUnlimited    2    

Быстрый фронт в базе размером 6.8 терабайт – наши стандарты при разработке и рефакторинге запросов

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

От быстродействия запросов, которые обращаются к крупным таблицам, напрямую зависит скорость работы всей базы в целом. Артем Кузнецов, тимлид команды 1С в компании ООО «Финтех решения» на конференции Infostart Event 2021 Moscow Premiere рассказал, как оптимизировать производительность при поддержке больших систем. Показал, на что следует обращать внимание при код-ревью запросов, как оптимизировать RLS, виртуальные таблицы, индексы и условия, и как доработка архитектуры решения может ускорить работу базы.

29.08.2022    4505    Chernazem    44    

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

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

22.01.2014    71395    yuraos    112    

Workaround me в 1С/MS SQL и не только, системный подход к созданию костылей

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

Workaround свидетельствует о невозможности решить проблему "правильным путем" и вызывает чувство стыда. Но практика показывает, что способность решать проблемы через workaround является порой единственным способом решить проблему в разумное время. А победителей, как говорят, не судят, так почему бы не создавать workaround по системе?

15.08.2022    990    1CUnlimited    0    

Ускорим проведение в 1С:Управление холдингом

HighLoad оптимизация Запросы Платформа 1С v8.3 1С:Управление холдингом Бесплатно (free)

В 1С:Управление холдингом есть "нехороший" запрос, который съедает значительную часть времени проведения документов. Если его подправить, то проведение заметно ускорится.

10.08.2022    4404    sapervodichka    57    

Миссия невыполнима. Общие реквизиты разделители против временных таблиц

HighLoad оптимизация Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

05.08.2022    1348    1CUnlimited    0    

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

HighLoad оптимизация Платформа 1С v8.3 1С:Управление торговлей 10 1С:Управление производственным предприятием Бесплатно (free)

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

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

Методика похудения для 1С – 100%

Свертка базы HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

28.07.2022    4774    1CUnlimited    37    

Экспертный кейс. История расследования одного небыстрого закрытия месяца в 1C:ERP. Пример неочевидных путей расследования в виде детективной истории

HighLoad оптимизация Механизмы платформы 1С Запросы Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

11.07.2022    4678    it-expertise    27    

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

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

19.02.2013    62849    Gilev.Vyacheslav    46    

Производительный режим работы RLS

HighLoad оптимизация Роли и права Платформа 1С v8.3 8.3.14 8.3.6 8.3.8 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х Бесплатно (free)

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Каждый из режимов имеет свои преимущества и недостатки относительно другого. Основные из них будут рассмотрены в данном материале.

14.06.2022    4666    Neti    6    

Любовь. Быстродействие. 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

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

26.05.2022    3524    vasilev2015    20    

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

HighLoad оптимизация Администрирование СУБД Платформа 1С v8.3 8.3.14 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

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

24.05.2022    3487    avolsed    15    

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

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

11.02.2013    38880    gallam99    19    

Заметки эксперта. Расследование длительного выполнения отчета “Движение ТМЦ и затрат в производстве” (1С:ERP 2)

HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Кратко: в ходе проведения нагрузочного тестирования “1С:ERP 2” под ОС Linux на СУБД Postgres выявлено существенное замедление формирования отчета “Движение ТМЦ и затрат в производстве” - до 60 минут. После проведенного расследования и точечной корректировки СКД в отчете, без изменения бизнес-логики результатов его работы, работа отчета была ускорена в 80 раз - средний показатель формирования составил 30 секунд.

19.05.2022    1926    it-expertise    19    

Тестирование - игровое моделирование

HighLoad оптимизация Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Мы рассмотрим подход к тестированию с применением элементов искусственного интеллекта

25.04.2022    1274    ivanov660    0    

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

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

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

03.11.2012    46009    madmpro    32    

Несколько слов про платформенный механизм оптимизации RLS

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Смотрим, как работает платформенный механизм оптимизации RLS, сравним поведение на разных СУБД MS SQL, Postgres 11,13,14.

07.04.2022    3341    ivanov660    23    

Почему после обновления Бухгалтерии в марте 2022 года отчеты стали такими медленными

HighLoad оптимизация Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Статья раскрывает причину, почему время формирования отчетов после обновления Бухгалтерии в марте 2022 сильно увеличилось. И рассказывает, как можно исправить ситуацию.

05.04.2022    4405    DBOdin_Lab    33    

Экспертный кейс. Расследование фатального замедления времени расчета себестоимости в 1С:ERP 2

HighLoad оптимизация Механизмы типовых конфигураций Запросы Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

При выполнении нагрузочного тестирования информационной системы на базе 1С:ERP для одного из клиентов с целью оценки возможности миграции системы на PostgreSQL и Astra Linux мы столкнулись с неприемлемым увеличением времени выполнения расчета себестоимости. Строго говоря, сценарий тестирования закрытия месяца не был выполнен вообще – он не укладывался в таймаут выполнения теста, 24 часа. По прошествии 18 часов всё ещё шло выполнение операции «Распределение затрат и расчет себестоимости». Более 16 часов выполнялся подэтап “Расчет партий и себестоимости. Этап. Расчет себестоимости: РассчитатьСтоимость”. Всё это время выполнялся запрос, который в текущей инфраструктуре клиента (СУБД MS SQL Server) выполняется чуть более 3 минут на аналогичных данных.

25.03.2022    4785    it-expertise    92    

Экспертный кейс. Расследование деградации производительности системы. Проведение документа “Поступление товаров и услуг” (1С:ERP 2)

Механизмы платформы 1С Запросы HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

В ходе проведения нагрузочного тестирования одним из наших клиентов была выявлена сильная деградация производительности системы в целом и, в частности, выполнения ключевой операции “Проведение документа поступление товаров и услуг” в течение выполнения теста. Согласно данным подсистемы БСП “Оценка производительности”, время выполнения ключевой операции “Проведение документа поступление товаров и услуг” возрастало в процессе тестирования с 15-20 секунд в начале тестирования до 150-200 секунд в его финале.

02.03.2022    3574    it-expertise    47    

Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками

HighLoad оптимизация Технологический журнал Платформа 1С v8.3 Бесплатно (free)

Рассмотрим по шагам процесс обнаружения, анализа и решения проблемы производительности на примере базы ERP, сравним отличия в работе Postgres и MS SQL.

28.02.2022    10293    ivanov660    18    

Ускорение работы конфигуратора 1С с большими прикладными решениями

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Ускорение работы 1С конфигуратора с большими прикладными решениями путем размещения системных каталогов 1С на RAM диске.

13.01.2022    6602    stg2005    105    

Ошибка производительности при проведении этапа 2.2 в ERP 2.4 и ERP 2.5

HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Хочется поделиться одним подводным камнем, с которым могут встретиться другие пользователи ERP. Искал решение в интернете, но ничего похожего не нашел. Поэтому решил создать эту тему.

06.12.2021    1548    Rokky78    6    

Повышение производительности веб-сервисов. Переиспользование сеансов

WEB-интеграция HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Повышение производительности веб-сервисов. Переиспользование сеансов. Практическая реализация.

20.10.2021    3937    sorter1    2    

Оптимизация проведения документов списания партий в УПП 1.3

HighLoad оптимизация Платформа 1С v8.3 1С:Управление торговлей 10 1С:Управление производственным предприятием Бесплатно (free)

Почти в каждой конфигурации УПП 1.3 (возможно, и в УТ 10.3) есть медленный запрос, тормозящий проведение документа списания. Данная публикация раскрывает места вызова данного запроса и приводит пример оптимизации. Пример показывает результаты проведения документа «Реализация товаров и услуг», но метод работает и для других документов списания партий.

09.09.2021    1216    info1i    5    

Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности

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

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

07.09.2021    11058    ivanov660    26    

Адекватный параллелизм в 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Параллелизм ускоряет выполнение тяжелых регламентных операций на СУБД, но может негативно влиять на работу многопользовательских учетных систем. О том, как анализировать влияние параллелизма и настраивать его для MS SQL и PostgreSQL, рассказал ведущий разработчик компании ООО МКК «Ваш Инвестор» Вадим Фоминых.

13.08.2021    11041    Shmell    8    

Распространенные ошибки разработчиков, приводящие к проблемам производительности

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

Рассмотрим примеры ошибок, анализ, исправление и мероприятия по недопущению подобного в будущем. Всего будет 18 примеров.

02.08.2021    14282    ivanov660    77    

Решение проблем при настройке счетчиков производительности

HighLoad оптимизация Платформа 1С v8.3 Россия Бесплатно (free)

Решение проблемы с заглавными буквами в power shell, поиск русского имени счетчика по английскому, и еще кое-что.

02.08.2021    1081    unichkin    4    

Parameter sniffing и генерация планов для разработчиков 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Особенности генерации планов запросов. Статья написана по мотивам вебинара Виктора Богачева.

01.06.2021    14044    vasilev2015    17    

Поиск причин блокировок СУБД

HighLoad оптимизация Платформа 1С v8.3 Управление блокировками Конфигурации 1cv8 Бесплатно (free)

Расследование блокировок СУБД. Статья написана по мотивам вебинара Виктора Богачева.

28.04.2021    7574    vasilev2015    14    

Тонкости эксплуатации, плюшки и особенности Postgres Pro Enterprise

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

В ходе онлайн-встречи INFOSTART MEETUP Novosibirsk Руководитель ИТ из компании ИнфоСофт Антон Дорошкевич поделился с коллегами тонкостями и опытом работы с Postgresql для 1С. 

22.04.2021    7005    a.doroshkevich    6    

Решение нестандартных проблем производительности на реальных примерах

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

На екатеринбургском Infostart Meetup выступил с докладом архитектор ИС центра разработки ФТО Александр Криулин. Он поделился с коллегами кейсами нестандартных проблем производительности и рассказал о способах их решения.

24.03.2021    7105    AlexKriulin    37    

Соединение вложенными циклами

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Nested loops и отсутствующие индексы. Статья написана по мотивам вебинара Виктора Богачева.

12.03.2021    4726    vasilev2015    22    

Долгое воспроизведение звука по RDP с удаленной машины

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

При воспроизведении короткого звука в 38 Кб, сигнализирующего об успешном сканировании, порою происходило подвисание примерно в 5 секунд.

09.02.2021    1557    pashamak    2    

Анализ блокировок СУБД: таблица изменений плана обмена 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Практический пример анализа типичной проблемы ожидания на блокировках СУБД, возникающих при использовании планов обмена 1С. Сервер СУБД: Microsoft SQL Server.

18.12.2020    5105    zhichkin    11    

Анализ проблем производительности по динамике мониторинга RAS 1C

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

07.10.2020    6837    ivanov660    13    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

HighLoad оптимизация Платформа 1С v8.3 1С:Документооборот Бесплатно (free)

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    6495    Iaskeliainen    16