Highload-оптимизация 1С: теория и практика на примере консолидированной отчетности группы "Магнит" и розничной аптечной сети "Магнит"

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

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

Тема оптимизации 1С на больших данных бесконечная и всеобъемлющая, поскольку на производительность влияет целый ряд факторов – количество пользователей, данных, транзакций, неоптимальные запросы и т.д. Об инструментах для локализации проблем производительности и практических кейсах оптимизации рассказал Алексей Олейник, руководитель сектора автоматизации отчетности МСФО компании «Информационные технологии Магнит».

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

 

 

Расскажу сначала немного о себе.

  • я уже 19 лет работаю с продуктами 1С;
  • долгое время проработал на должности руководителя ИТ в Юг-авто, и получил там очень большой опыт, которым с вами поделюсь;
  • в настоящее время занимаю должность руководителя сектора по автоматизации отчетности МСФО в розничной аптечной сети Магнит.

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

 

 

Расскажу немного о своих работодателях, чтобы образовать у вас какое-то понятие – в каком случае действительно нужна Highload-оптимизация.

Все знают Магнит:

  • 25 лет на рынке,
  • 20 тысяч магазинов,
  • тысяча аптек,
  • своя логистика, свое производство – много чего своего, и значительная часть из этого автоматизирована на программных продуктах 1С.

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

 

 

Второй пример – Юг-Авто, сеть дилерских центров на юге России.

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

 

Практика

 

 

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

  • Первый проект – это «Аптеки Магнит». Все аптеки Магнита работают на программном продукте 1С «Управление аптечной сетью». Это – отраслевка, тиражная коробка, построенная на «Управление торговлей 11», естественно, с доработками, которые нужны для аптечников.

  • Следующий пример – это МСФО Магнит, все это собирается в 1С:Консолидацию КОРП. В отличие от практически коробочного решения в «Управлении аптеками» здесь было сделано очень большое количество доработок, которые были предназначены именно для обеспечения достаточного уровня производительности, для обработки такого огромного объема данными. Удивительно, но консолидация всей информации действительно стекается в базу 1С и там дальше после этого уже передается на следующий уровень обработки.

  • И последний пример будет скорее обзорный – Юг-Авто имеет в эксплуатации большое количество продуктов 1С от Документооборота до Управление торговлей 10.3. Что делать с этими продуктами, чтобы они могли выдерживать работу несколько сотен пользователей, я тоже вкратце расскажу. Насколько сложно было заставить 7.7 выдерживать более сотни пользователей, столь же тяжело заставлять систему, не предназначенного для этого объема для того, чтобы они потянули несколько сотен пользователей.

 

Метрики

 

 

Когда заходим на проект и вообще начинаем задумываться над оптимизацией, нам нужно получить какую-то числовую оценку текущей ситуации, чтобы в дальнейшем отслеживать то, что мы делаем – идет в плюс, в минус или же мы ничего не добились. Это называется «метрики».

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

К чему же должна приводить оптимизация?

  • Прежде всего, естественно, это снижение нагрузки на оборудование. 1С редко тормозит просто так – как правило, это происходит из-за увеличения нагрузки на клиентские машины, на сервер 1С:Предприятие либо на СУБД. Оптимизируем – повышаем производительность.

  • Следующее – это снижение времени отклика на какие-то операции, которые у нас есть в системе. Либо на конкретную пользовательскую операцию, либо, возможно, на веб-сервис.

  • Естественно, должен повышаться коэффициент APDEX – это интегральный показатель удовлетворенности пользователей скоростью системы. Чем выше – тем лучше. Идеальный показатель принимается равным единице, но это практически недостижимо. Входишь на проект с показателем APDEX равным 0,1-0,2, выходишь с показателем 0,8 – отлично, значит, мы не просто так потрудились.

  • И возможно, самое важное, но самое сложное для восприятия – это количество инцидентов, связанных с производительностью системы, когда пользователи жалуются, что у них там тормозит, висит. Когда мы снижаем количество инцидентов, связанных с производительностью, автоматически повышается стабильность системы, потому что платформа 1С очень плохо себя ведет, если у вас процессор загружен на 100%, не хватает места на tempdb, переполняется журнал транзакций – это все практически всегда приводит к перезагрузке сервера 1С, к значит, к снижению стабильности.

 

Разный Highload

 

 

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

  • Простейшая самая известная – это большое количество пользователей. Какие метрики следует снимать в этом случае? Естественно, нагрузка на оборудование, чтобы понимать, есть ли какой-то запас по увеличению количества пользователей либо эффективности работы пользователей. И снимаем метрику по APDEX – стали ли пользователи довольнее или нет.

  • Второй возможный вариант – когда система обрабатывает множество идентичных или очень похожих транзакций. Когда у нас есть какой-нибудь сервис, в который мы заливаем огромный поток данных (биллинговая система или АСУ ТП), тогда нам необходимо повысить количество транзакций, которые система сможет переварить в секунду. Цель достижима, метрика есть. Можно над ней работать.

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

  • Legacy-системы. С ними тяжелее всего, потому что в них практически нет метрик. Что можно сделать? Посмотреть нагрузку на систему – насколько у нас железо загружено. И количество инцидентов посчитать – насколько часто пользователи у нас обращаются за какой-нибудь ерундой.

Выскажу очень спорный, но, тем не менее, правдивый тезис:

«1С – это решение, обеспечивающее высокую производительность»

Сразу скажу, что это относится только к современным решениям, построенным на «1С:ERP» либо «1С:Документооборот», а не «Бухгалтерия 1.6» или что-нибудь со времен 7.7.

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

 

Влияние на производительность

 

 

В чем же бывают проблемы? Сразу скажу, что здесь я никаким образом не описываю проблемы, возникающие из-за неправильной работы железа, отсутствия настройки планов обслуживания СУБД или нехватки памяти – это все очевидно, тривиально, на этом заострять внимание не буду.

С чем чаще всего бывают проблемы?

  • Удивительно, но это локальные доработки – то, что сделано нами на конкретных предприятиях. Зачастую это использование нестандартным образом функциональности, которая заложена в 1С.

  • Очень часто проблемы с партнерскими решениями – отраслевые решения либо какие-то специфические доработки, сделанные партнерами (даже в коробках – коробка ни о чем не говорит, ничего не гарантирует)

  • Часто проблемы возникают на уровне MS SQL – приходится этим заниматься, оптимизировать, какие-то ситуации разбирать. Готовых решений здесь не бывает. Но тем не менее, MS SQL часто подкидывает нам проблем.

  • Типовая конфигурация тоже иногда (но гораздо реже, чем все остальное) имеет какие-то проблемы. Редко, но бывает.

  • Очень редко – проблемы в платформе. В большинстве случаев платформа отрабатывает хорошо. Разве что мы не умеем ее «готовить».

  • По поводу «готовить» я имею в виду состав данных, которые есть в конкретной вашей базе. Это одна из самых главных и самых часто встречаемых причин, влияющих на производительность. Потому что если у вас не закрыты регистры накопления себестоимости, если вы в ERP ввели 20-30 тысяч направлений деятельности, вам ничего не поможет – только закрывать регистры, правильно настраивать логику системы или же пересматривать подход к использованию тех или иных решений, которые предлагает нам фирма «1С».

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

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

 

Практические кейсы оптимизации. Отчет о розничных продажах УТ11

 

 

В качестве примера мой первый практический кейс. Это кусок типового кода – заполнение «Отчета о розничных продажах». Это не проведение, а именно заполнение, создание. Поступила задача оптимизировать этот блок, он выполнялся недостаточно производительно, долго. Сняли замеры производительности конфигуратором, вывели этот запрос.

Казалось бы, элементарный запрос, который обращается к временной таблице «ЧекиККМ», и фильтрует по ней выборку из табличной части «Серии» документа «ЧекККМ». Этот запрос выполнялся 28 секунд, хотя в самой табличной части серий содержалось всего лишь несколько сотен записей – ерунда.

В чем была проблема? СУБД MS SQL восприняла этот запрос не в качестве отбора по ссылке из табличной части, а она сделала слияние всей огромной табличной части ЧекиККМ.Серии с нашими 300 записей, при том что в этой табличной части несколько десятков миллионов записей.

Это возникало из-за того, что поле «Ссылка» во временной таблице «ЧекиККМ» было полем составного типа. При передаче такого запроса в SQL он преобразовывался в CASE-операцию, не воспринимая условие как прямое сравнение, а выполняя более очевидную для него функцию слияния.

Метод решения – мы убрали поле составного типа из временной таблицы «ЧекиККМ». Теперь в каждой временной таблице только лишь один тип значения в этом поле. Время выполнения сократилось с 28 секунд до 0.4 секунды. Это примерно в 60 раз. Мы зарегистрировали эту ошибку в 1С. В ERP 2.5.5 будет исправление по этой теме.

Также в рамках расследования этого инцидента фирма «1С» зарегистрировала ошибку в платформе и в платформе 8.3.17 блок про оптимизацию – это как раз связан с тем, что запрос преобразовывался в CASE-операцию. Они исправили и платформу и типовую конфигурацию.

Фирма «1С» достаточно оперативно реагирует на те обращения, которые мы пишем, и делает вывод из проблем производительности, которые возникают. Естественно, фирме «1С» интересно делать свою коробку более масштабируемой, более производительной.

 

Влияние версии SQL Server

 

 

Мы пробовали запустить тот же самый запрос на более старой версии SQL-сервера. Изначально тестировали на платформе 8.3.15+SQL 2016, попробовали запустить на MS SQL 2012 сервере, подумали – ну как-то это же работает у всех, страна большая, должно работать. Оказалось, что на MS SQL2012 все это работает еще хуже – на эту операцию уходило 100 секунд.

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

В SQL-сервере, обращаю внимание, есть не только версия самой программы SQL-сервера, есть уровень совместимости.

Если вы внаглую на 2012-м сервере воткнете 2019, этого недостаточно, нужно сменить уровень совместимости. Но это все нужно обязательно тестировать, потому что всплыть может в самом неожиданном месте.

По поводу актуализации редакций.

  • По производительности сервера ниже 2012 я вам ничего сказать не могу, но если у вас версия моложе, чем 2014 – если у вас 2008, 2012 сервер – вам однозначно нужно обновляться.

  • 2014 сервере гораздо лучше СУБД понимает сложность выполнения запроса и исходя из этого подбирает план выполнения.

  • 2016-й сервер будет гораздо лучше нагружать ваш процессор на сервере.

  • 2017-й сервер будет гораздо лучше использовать оперативную память на сервере, гораздо реже СУБД будет обращаться к tempDB, к жесткому диску. Обновляйте версии до актуального состояния.

 

Инструменты

 

 

Какие инструменты мы используем для того, чтобы оптимизировать? Ничего странного, ничего страшного, ничего фантастически дорогого.

  • С помощью Zabbix собираем статистику нагрузки на оборудование. Бесплатный инструмент, быстро настраивается.

  • С помощью MS SQL Server Management studio – мы выполняем запросы, которые показывают топ-нагрузки на оборудование в разрезе конкретных запросов. Смотрим, какой запрос дает нагрузку, смотрим план выполнения этого запроса, там же можно понять, какой пользователь выполняет этот запрос.

  • APDEX – я про него уже говорил

  • 1С:ЦУП (1С:Центр управления производительностью) мы используем достаточно редко, потому что на больших объемах техжурнала он просто умирает. Если мы собираем за полчаса техжурнал, он обрабатывается неделю. Блокировки – да, мы там смотрим

Все эти инструменты нам нужны для анализа статистических данных.

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

  • Самое простое и очевидное – конфигуратор. Замер производительности, когда мы сделали замер производительности, по крайней мере, становится понятно, какие строчки кода, какие запросы у нас радикально влияют на производительность. Метод решения выявляется именно оттуда.

  • Если проблема с запросом – тогда запускаем профайлер и снимаем трейс, трейс открываем в Studio и смотрим, что там такого нехорошего, перестраиваем.

  • Метод решения – естественно, подключаем свое мышление, и пытаемся адаптировать. В 1С у нас очень ограниченный язык программирования на MS SQL. Поэтому приходится какими-то обходными путями заставлять СУБД делать то, что мы хотим.

  • Никаких готовых ответов в интернете по оптимизации 1С на больших объемах данных вы, скорее всего, не найдете. Есть какие-то общие концепты, но готового решения нет.

 

Практические кейсы оптимизации. Много пользователей

 

 

Переходим к практическим кейсам. В «1С:Управление аптечной сетью» у нас большое пользователей (несколько тысяч человек) в онлайне заводит документы, при этом данные загружаются и выгружаются регламентными заданиями в большом количестве потоков.

  • В таких условиях возникает невоспроизводимая нагрузка, которая проявляется самым разнообразным образом. И если мы спросим пользователя: «Что ты такого сделал, что у нас из-за тебя упал сервер?» он в большинстве случаев ответит что-то невразумительное: «Я что-то там нажал, после чего все погасло». И даже если он закроет программу, запрос все равно продолжит выполняться на сервере, и пока вы не удалите его сеанс принудительно, система продолжит «висеть». Метод решения – снимаем зависший сеанс, смотрим в MS SQL Management Studio, какой запрос у нас выполняется, смотрим его план, пытаемся воспроизвести параметры, которые были в него переданы. И таким образом вылавливаем ситуацию. Естественно, это все не просто, не дешево и не быстро.

  • RLS – кто-то их любит, кто-то не любит, но без них жить невозможно. В свежей БСП появился производительный режим RLS. Советую вам попробовать, может быть, с ним будет лучше.

  • Еще одна из проблем – это отсутствие обратной связи. Когда у вас большое количество пользователей, то, скорее всего, есть какая-нибудь служба поддержки. Но поскольку вы находитесь где-нибудь на четвертой линии, а то и вообще работаете внешними консультантами, то информация о том, что что-то стало не так, дойдет до вас очень нескоро. Тут остается опять же, самостоятельно мониторить тот же самый Zabbix, если с сервером действительно происходит что-то печальное, вы это увидите в метриках.

 

Практические кейсы оптимизации. Много транзакций

 

 

Там же в «Аптеках» мы столкнулись с еще одной особенностью – обработка большого количества транзакций (в сети аптек Магнит ежесекундно проводится несколько чеков ККМ – за 10 секунд в системе прибавляется 30-40 чеков).

В чем преимущество этой ситуации? То, что вы можете конкретную операцию чуть ли не до блеска вычистить.

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

Проект по оптимизации аптек Магнит у нас до сих пор идет, скорее всего, это бесконечная вещь, но расчеты показывают, что по результатам проведенных оптимизационных мероприятий емкость системы увеличится раз в 10. То же самое оборудование позволит обслуживать примерно в 10 раз больше пользователей. Фактически, это ключевой показатель системы.

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

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

 

Практические кейсы оптимизации. Сегменты номенклатуры

 

 

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

Простейший код. Он у нас выполнялся несколько секунд. Для аптеки это недопустимо много.

Посмотрели план выполнения – оказалось, что проблема в том, что в УТ было 4 колонки – Номенклатура, Склад, Характеристика и Серия. Причем, Номенклатур и Характеристик гораздо меньше, чем строк в этой таблице. А нас интересовали именно различные сегменты, которые есть в этой таблице.

 

 

Метод решения – переписать код и сделать вложенный запрос, где мы выбираем прямо из этой временной таблицы РАЗЛИЧНЫЕ Номенклатура, Характеристика. И после этого уже производим слияние с регистром сведений НоменклатураСегмента.

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

Мелочь, но приятно.

 

Практические кейсы оптимизации. Много данных

 

 

Мой следующий практический кейс – миллионы строк в одном документе.

Этот пример касается конфигурации 1С:Консолидация, куда мы консолидировали данные для МСФО. Там достаточно легкая конфигурация по объему – небольшое количество алгоритмов, но очень много данных. Поэтому каждую операцию мы оптимизировали до идеального состояния. По результатам проекта время выполнения тяжелых операций сократилось с 8 часов примерно до 20-30 минут.

Если мы говорим про обработку больших данных, то 20-30 минут это тоже может быть очень быстро, если смотреть, с чего начинали.

 

Практические кейсы оптимизации. Legacy-системы

 

 

И последний кейс – поддержка устаревающих систем.

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

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

 

Техники ускорения

 

 

Тема оптимизации бесконечная и всеобъемлющая, но если собрать вместе техники ускорения их получится не так много:

  • Первый способ оптимизации – это отсечь лишнее (чтобы СУБД или 1С не выполняла что-то лишнее). Был практический пример, когда у нас один кусок кода выполнялся во время проведения документа четыре раза. Привели к тому, что он стал выполняться один раз вместо четырех. Ускорилось проведение на 30%. Когда сделали так, чтобы этот кусок кода не выполнял лишние операции, его выполнение ускорилось еще в 20 раз. Итого, время проведения сократилось в два раза.

 

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

  • По поводу «Убрать ненужные индексы» можно говорить очень долго и упорно – не один день даже говорить. Вкратце – убивайте лишние индексы, добавляйте те, которые вам нужны. Это очень важно, это полностью меняет работу всей системы.

 

 

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

 

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

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

Приглашаем всех принять участие в тематических митапах Инфостарта: infostart.ru/events/

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Repich 521 11.01.21 13:16 Сейчас в теме
И напоследок, самая последняя особенность – это ускорение производительности за счет использования циклов в одну строку. Я в это не верил, но это действительно так. Первый кусок кода работает медленнее, чем второй кусок кода в пять с лишним раз.

Можно реальный пример ускорения? Не синтетический тест с циклом со сложением.
1С говорят с отключенной отладкой не будет работать это.
8. kurpekov 41 13.01.21 10:56 Сейчас в теме
(1) Только что попробовал на разных компьютерах и серваках - где есть разница, где - нет (ну, там 5-10 процентов). Чаще всего разницы нет.
2. Ks_83 223 11.01.21 13:43 Сейчас в теме
ускорение производительности за счет использования циклов в одну строку

Колдунсвто
3. Ks_83 223 11.01.21 13:52 Сейчас в теме
Обработка не в СУБД. Я часто встречаю пример, как на слайде – когда данные выгружаются из запроса в промежуточную таблицу значений, чтобы передать их в другой запрос. Так делать не нужно. Если эта таблица значений вам на сервере 1С не нужна, не выгружайте ее из запроса – сохраняйте все во временных таблицах и передавайте их в другой запрос непосредственно через менеджер временных таблиц.

Есть мнение, что менеджера тоже лучше избегать, ибо он скидывает таблицы на диск.
11. user662404_itlexusss 8 15.01.21 13:13 Сейчас в теме
(3) Таблица значений тоже сохраняется на диск в сеансовые данные. Но это ерунда, по сравнению с временем, затрачиваемым при передачи больших ТЗ с сервера 1С на СУБД, Делается это пачками по 10 тысяч строк через BULK INSERT, но сильно легче от этого не становится. Причем пишется опять же во временную таблицу на диск.
Гораздо производительнее записать прямо на СУБД во временную таблицу, не спуская массив на сервер 1С.
4. TMV 14 12.01.21 07:22 Сейчас в теме
1. В видео беспардонно обрезали докладчика - как-то не красиво получилось.
5. TMV 14 12.01.21 07:40 Сейчас в теме
2. По чекам. Дело в этом:
ЧекККМСерии.Ссылка.ВидЦены КАК ВидЦены

а нужно:
ВЫРАЗИТЬ(ЧекККМСерии.Ссылка КАК Документ.ЧекККМ).ВидЦены КАК ВидЦены


З.Ы.
Может стоило вообще через внутреннее соединение сделать типа так:
ЧекиККМ.ВидЦены КАК ВидЦены
ИЗ
	Документ.ЧекККМ.Серии КАК ЧекККМСерии
	ВНУТРЕННЕЕ СОЕДИНЕНИЕ ЧекиККМ КАК ЧекиККМ
	ПО ЧекККМСерии.Ссылка = ЧекиККМ.Ссылка
		И ЧекиККМ.Коррекция = ЛОЖЬ
12. user662404_itlexusss 8 15.01.21 13:27 Сейчас в теме
(5)ЧекККМСерии - это табличная часть документа ЧекККМ. В нем Ссылка всегда строго типизирована, поэтому транслятор 1С запросов на СУБД просто проигнорирует Ваше "ВЫРАЗИТЬ(...)".
Проблема была в ЧекиККМ.Ссылка, а точнее соединение по этому полю. Транслятор 1С не видел, что идет соединение с полем одного типа, поэтому интерпретировал "ПО ЧекиККМ.Ссылка = ЧекиККМСерии.Ссылка" во что-то подобное
"ON CASE WHEN ЧекиККМ.RTRef = 0x... THEN ЧекиККМ.RRef END = ЧекиККМСерии._IDRef".
В свою очередь оптимизатор MS SQL 2017 увидел слева от "ON" нелюбимую конструкцию "CASE WHEN" и решил сделать HASH JOIN вместо очевидного LOOP JOIN. Поэтому система и считала хеши по всей таблице табличной части чеков ККМ, а когда их у Вас миллиарды, хеши считаются ооооочень долго.
Оптимизатор MS SQL 2012 и ниже делал еще хуже. Подробностей не помню, но был какой-то жесткий Lazy spool.
15. triviumfan 24 19.01.21 16:05 Сейчас в теме
(12) Не верю, скуль болен или намудрили чего. Не может он интерпретировать case в соединении, если в обоих таблицах ссылка одного типа.
6. TMV 14 12.01.21 07:42 Сейчас в теме
3. По промежуточной таблице. Обычно так делают, если она подлежит некой обработке кодом, и только после (а не сразу) помещается в запрос.
13. user662404_itlexusss 8 15.01.21 13:30 Сейчас в теме
(6) Гораздо производительнее эту обработку кодом сделать в виде запроса 1С. Кто получал профильное программистское образование должны помнить, как мы реализовывали исполнение алгоритмах на разных абстракциях, вроде конечных автоматов. Так и в 1С - практически любой код можно переложить в запрос. А на больших объемах данных, обработка запросом гораздо производительнее.
7. AneJIbcuH 31 12.01.21 08:10 Сейчас в теме
Метод решения – переписать код и сделать вложенный запрос, где мы выбираем прямо из этой временной таблицы РАЗЛИЧНЫЕ Номенклатура, Характеристика. И после этого уже производим слияние с регистром сведений НоменклатураСегмента.


1С говорят, соединение с вложенным запросом - это плохо.
10. leongl 379 13.01.21 21:05 Сейчас в теме
(7)Это как в детстве говорили - это огонь, не подходи, не трогай, бойся). Важен вдумчивый подход, а не бездумное клепание временных таблиц, что автор и донес.
14. user662404_itlexusss 8 15.01.21 14:03 Сейчас в теме
(7) На самом деле, в изначальном тексте есть вложенный запрос, просто Вы его не видите. В плане выполнения же он есть: внешний запрос - это конструкция РАЗЛИЧНЫЕ, а вложенный - это соединение таблиц.
В изначальном варианте, соединялись две таблицы и на результате их соединения уже выполнялись РАЗЛИЧНЫЕ (конструкции HASH AGGREGATE или последовательно "SORT + STEAM AGGREGATE"). Причем это очень тяжелые конструкции, которые имеют дурную привычку лезть в TempDB (если ошибаются с ожидаемым количеством строк).
После оптимизации, тяжелая операция РАЗЛИЧНЫЕ выполняется на гораздо меньшем множестве строк, еще до его умножения на количество сегментов. Отличия производительности тем больше, чем больше сегментов.
Оставьте свое сообщение

См. также

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

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

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

30.10.2017    31244    MrWonder    42    

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

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

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

24.03.2021    2792    AlexKriulin    36    

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

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

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

09.02.2021    547    pashamak    2    

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

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

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

18.12.2020    2090    zhichkin    5    

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

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

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

22.04.2015    42316    Gilev.Vyacheslav    1    

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

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

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

07.10.2020    3991    ivanov660    12    

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

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

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

02.10.2020    4633    Nykyanen    16    

Тест скорости работы мобильной платформы 1С

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

С помощью этого приложения вы можете измерить производительность своего устройства, используя для этого мобильную платформу 1С:Предприятие. Набор действий теста полностью повторяет аналогичный тест для стационарных ПК, поэтому результаты сравнимы.

14.09.2020    1541    capitan    25    

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

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

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

22.01.2014    68278    yuraos    112    

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

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

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

19.08.2020    16365    YPermitin    30    

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

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

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

17.08.2020    686    ivanov660    0    

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

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

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

14.08.2020    12324    dmurk    31    

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

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

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

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

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

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

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

20.07.2020    2341    Филин    7    

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

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

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

25.06.2020    3333    ivanov660    13    

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

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

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

24.05.2020    9249    DataReducer    22    

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

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

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

19.02.2013    57373    Gilev.Vyacheslav    46    

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

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

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

18.05.2020    2433    Aleksey.Bochkov    4    

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

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

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

06.04.2020    13769    YPermitin    0    

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

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

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

03.04.2020    6297    feva    15    

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

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

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

11.02.2013    32333    gallam99    19    

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

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

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

31.03.2020    14697    informa1555    35    

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

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

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

31.03.2020    3470    vasilev2015    10    

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

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

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

20.03.2020    5996    vasilev2015    27    

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

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

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

03.11.2012    44956    madmpro    32    

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

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

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

18.03.2020    7975    kaliuzhnyi    44    

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

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

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

17.02.2020    12013    Evil Beaver    13    

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

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

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

23.01.2020    6974    darkdan77    59    

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

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

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

23.01.2020    9113    Kaval88    26    

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

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

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

19.12.2019    13577    ivanov660    20    

Весёлые картинки о работе 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    8246    EugeneSemyonov    11    

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

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

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

14.10.2019    19816    YPermitin    31    

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

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

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

13.09.2019    9653    Repich    5    

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

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

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

10.09.2019    20346    Sloth    30    

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

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

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

09.09.2019    9387    2tvad    17    

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

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

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

19.07.2019    9370    Филин    12    

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

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

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

16.07.2019    11219    fhqhelp    0    

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

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

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

02.07.2019    11992    igordynets    120    

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

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

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

27.06.2019    10350    YPermitin    17    

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

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

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

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

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

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

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

13.06.2019    13178    Repich    117    

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

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

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

13.06.2019    6143    slayer-ekb    10    

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

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

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

11.06.2019    27759    dmurk    146    

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

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

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

28.05.2019    22340    ivanov660    11    

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

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

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

21.05.2019    8342    vasilev2015    21