Под ключевой операцией я понимаю действие, которое можно назвать и измерить: проведение заказа, открытие списка документов, расчет себестоимости, загрузка заказов с сайта, печать этикетки, закрытие месяца, обмен с внешней системой, выполнение регламентного задания. Фраза «у нас тормозит 1С» для анализа почти бесполезна. А вот «заказ клиента проводится 38 секунд в рабочее время и 6 секунд вечером» - это уже нормальная отправная точка. Ключевая операция — это не абстрактное "база тормозит", а конкретная строка в отчёте: "Проведение РеализацииТоваровУслуг — 38 секунд, 214 раз в день, ответственный — Иванов И.И., отдел продаж".
Как я оказался в теме производительности
С 1С я работаю с 2008 года. Начинал, как и многие, во франчайзи: обновления, доработки, отчеты, обмены, исправление чужого кода и срочные задачи, которые часто появлялись в конце рабочего дня. За годы работы я прошел множество курсов, видел разные конфигурации, проходил сертификацию и в какой-то момент был уверен, что неплохо знаю платформу и удивить меня уже сложно.
Потом я пришел ведущим 1С-разработчиком в крупную компанию, занимавшуюся торговлей. Размер рабочей базы превышал 2,1 ТБ, а в часы нагрузки система могла принимать более 2000 заказов в час. Код, который на небольшой базе отрабатывает за доли секунды, на реальных данных может занимать минуты, создавать блокировки и влиять на десятки параллельных процессов.
В первые недели аналитики принесли мне довольно большой список ключевых операций. Для каждой было указано фактическое время, критичность для бизнеса, период возникновения проблемы и сотрудник, который лучше всего воспроизводил ситуацию. В списке были не только тяжелые отчеты. Там встречались обычное проведение документов, загрузка заказов, открытие формы, печать, фоновые задания и обмены.
Это был полезный момент отрезвления. Одно дело — знать синтаксис запросов и уметь пользоваться замером производительности. Совсем другое — отвечать за систему, где задержка одной операции влияет на склад, продажи, колл-центр и отгрузку.
После этого я глубоко погрузился в тему. Покупал практически все профильное обучение, которое мог найти, разбирал чужие кейсы, изучал планы запросов, технологический журнал, блокировки, работу СУБД и поведение платформы под нагрузкой. Рабочего времени на это не хватало, поэтому значительная часть экспериментов проходила вечером и в выходные на тестовых копиях. Часть рекомендаций подтверждалась сразу, часть красиво звучала только в презентации, а на реальной базе не давала заметного эффекта. Со временем накопился набор признаков, которые я проверяю почти автоматически.
Ниже — не полный справочник по производительности. Это список причин, которые регулярно встречаются в реальных системах и действительно способны превратить обычную операцию в многоминутное ожидание.
Почему новый сервер - не первый шаг
Оборудование действительно может быть узким местом. Я видел серверы с заполненным диском, нехваткой памяти, медленной tempdb и процессором, который постоянно находился под полной нагрузкой. В таких случаях инфраструктуру надо менять.
Но новый сервер не исправит запрос в цикле. Не добавит индекс в нужное место. Не сократит транзакцию, которая удерживает блокировки несколько минут. Он просто быстрее выполнит неудачный алгоритм - до тех пор, пока база снова не вырастет.
Поэтому я обычно иду в таком порядке: фиксирую конкретную операцию, повторяю замер, определяю, где уходит время, разбираю запросы и ожидания, исправляю код. И уже после этого становится понятно, нужен ли более быстрый диск, дополнительная память или изменение настроек СУБД.
1. Отбор по полю без подходящего индекса
Это одна из самых частых причин. В запросе есть обычное условие:
ГДЕ
Контрагенты.ВнешнийИдентификатор = &ВнешнийИдентификатор
На экране все выглядит логично: передали идентификатор, получили контрагента. Но если подходящего индекса нет, СУБД может читать большую часть таблицы, чтобы вернуть одну строку.
Здесь важно не путать два утверждения. «Поле индексируется» и «запрос использует подходящий индекс» - не одно и то же. Может существовать составной индекс, но нужное поле стоит в нем не на той позиции. Может выполняться преобразование типа. Может быть настолько низкая селективность, что оптимизатор предпочтет сканирование.
Первое, на что я смотрю: сколько строк запрос вернул и сколько прочитал (через план запросов). Если вернул 12 строк, а просмотрел несколько миллионов, это не всегда ошибка, но это уже вопрос, на который нужен ответ.
Индексировать каждый реквизит тоже не надо. Индекс занимает место и добавляет работу при записи. На нагруженной базе бессистемное добавление индексов легко ускоряет один отчет и одновременно замедляет проведение документов. Поэтому индекс должен появляться под повторяемый сценарий, а не «на всякий случай».
2. Соединение таблиц по неиндексированным полям
Если для поля соединения нет подходящего индекса, SQL Server может быть вынужден прочитать значительную часть одной или обеих таблиц. Какой именно алгоритм он выберет — Nested Loops, Hash Match или Merge Join — зависит от объема данных, статистики и других условий. Но результат часто один: вместо нескольких тысяч нужных строк запрос обрабатывает сотни тысяч или миллионы.
На одном из проектов табличная часть документа «Поступление товаров и услуг» соединялась с регистром сведений «Дополнительная информация по поставкам» по реквизиту «Номер партии». Изначально этот реквизит не создавался как ключ связи и не был проиндексирован, хотя с точки зрения бизнес-логики соединение было правильным. Запрос возвращал корректные данные, но выполнялся 51 секунду вместо ожидаемых долей секунды.
В фактическом плане выполнения использовался Hash Match, а через один из его входов проходило около 1,8 млн строк. Для получения итоговой выборки требовалось прочитать практически весь регистр. При одновременном запуске нескольких экземпляров запроса нагрузка на SQL Server резко возрастала, из-за чего замедлялись и другие операции системы.
После включения индексирования реквизита «Номер партии» в регистре сведений SQL Server смог использовать более точечный доступ к данным. Время выполнения запроса сократилось с 51 до 0,3 секунды.
В ситуациях, когда изменить структуру исходной таблицы было нельзя, сначала отбирался небольшой необходимый набор данных во временную таблицу. Для нее создавался индекс по полю соединения, после чего основной запрос работал уже с подготовленным набором, а не со всей исходной таблицей.
Важно, что временная таблица помогает только тогда, когда она действительно сокращает объем обрабатываемых данных или позволяет один раз подготовить результат. Простое копирование большой таблицы во временную обычно ускорения не дает.
3. Универсальный запрос с несколькими ИЛИ
Конструкция вида «Поле1 = &Параметр1 ИЛИ Поле2 = &Параметр2» — это, наверное, самая недооценённая по вредности вещь, которую я видел в запросах. Проблема в том, что оптимизатор СУБД плохо умеет строить эффективный план выполнения для условий через ИЛИ, особенно когда поля из разных таблиц или разных индексов. В итоге вместо двух быстрых обращений по индексу мы получаем один медленный полный проход по всем задействованным таблицам.
Особенно больно это в запросах с отбором вида «НомерДокумента = &Параметр ИЛИ ДатаДокумента = &Параметр ИЛИ Контрагент = &Параметр», которые часто пишут для «универсального поиска». Каждое такое ИЛИ добавляет разработчику ощущение гибкости и одновременно рушит производительность на больших объёмах, потому что оптимизатор вынужден страховаться и брать план, который гарантированно сработает при любом из условий, — а это, как правило, самый неэффективный план из возможных.
Решение, которое почти всегда работает: разбить запрос через ОБЪЕДИНИТЬ ВСЕ на несколько отдельных запросов, каждый из которых использует ровно одно условие, соответственно, ровно один индекс. Да, текст запроса становится длиннее и выглядит менее элегантно. Но вместо одного плана с полным сканированием таблицы вы получаете несколько планов с точечным попаданием по индексу — и суммарно это почти всегда быстрее, иногда на порядок.
4. Подзапрос в условиях запроса
Подзапросы сами по себе не зло. Это важно сказать, потому что в теме производительности слишком много правил вида «никогда не используйте...». Использовать можно. Вопрос в объеме и плане выполнения.
Проблемный вариант обычно выглядит компактно:
ГДЕ
Реализация.Ссылка В
(ВЫБРАТЬ
Движения.Регистратор
ИЗ
РегистрНакопления.ОстаткиНаСкладах КАК Движения
ГДЕ
Движения.Период МЕЖДУ &Начало И &Конец)
Затем внутри подзапроса появляются еще два соединения, проверка типа, дополнительное свойство и группировка. Внешний запрос занимает полстраницы, а реальная работа происходит внутри условия.
В таких местах мне часто помогает простое действие: вынести набор регистраторов во временную таблицу и отдельно посмотреть, сколько там строк. Не для «ускорения временной таблицей», а для понимания. Иногда выясняется, что промежуточный набор в десять или двадцать раз больше ожидаемого из-за дублей. После явного выделения это видно сразу.
У меня был случай с отбором номенклатуры, которая присутствует в открытых заказах: разработчик написал условие через подзапрос прямо в секции ГДЕ основного запроса. Логически всё верно, запрос выполнялся, но при увеличении количества заказов время выполнения начало расти нелинейно — подзапрос выполнялся снова и снова для каждой строки перебираемой номенклатуры.
Лечится это вынесением подзапроса в отдельный запрос с сохранением во временную таблицу и последующим соединением с этой временной таблицей вместо подзапроса в условии. СУБД выполняет подзапрос один раз, кладёт результат в компактную временную таблицу с нужным индексом, а дальше работает с ней как с обычным соединением. Разница на объёме в несколько десятков тысяч строк была в буквальном смысле между «3 минуты» и «5 секунд».
5. Получение данных через точку
Оператор точки - одна из причин, по которым запросы 1С удобно писать и трудно анализировать.
Заказ.Контрагент.ИНН
Для разработчика это одно поле. Для платформы - необходимость получить контрагента и обратиться к его таблице. Если цепочка длиннее, соединений становится больше. Если тип составной, SQL может заметно усложниться.
Это тонкий момент, который многие разработчики 1С даже не замечают как проблему, потому что в конфигураторе всё выглядит невинно: «Документ.Ссылка.Контрагент.ИНН». Но если поле «Ссылка» имеет составной тип — то есть документ может быть одним из нескольких видов, — то платформа при построении запроса вынуждена генерировать соединение (левое внешнее, как правило) с каждой из таблиц, соответствующих каждому виду документа в составном типе. Даже если фактически в данных встречается только один вид документа.
Представьте, что у вас в составном типе десять возможных видов документов, а обращение через точку идёт к реквизиту, который в итоге хранится в одном месте. Платформа честно построит десять левых соединений, из которых девять всегда будут пустыми, — и всё это ради того, чтобы достать одно поле. На больших таблицах это ощутимая просадка производительности просто на пустом месте, потому что СУБД реально выполняет эту работу, даже если результат предсказуем.
6. Запрос в цикле: любимая причина больших ускорений
Из всех пунктов этот, пожалуй, самый благодарный. Его легко объяснить, легко измерить и часто легко исправить.
Для Каждого Строка Из Данные Цикл
Номенклатура = Справочники.Номенклатура.НайтиПоНаименованию(
Строка.Наименование);
КонецЦикла;
В коде нет объекта Запрос, поэтому фрагмент выглядит безобидно. Но НайтиПоНаименованию должен обратиться к базе. Если загружается 50 000 строк, потенциально получаем 50 000 отдельных поисков.
Посчитаем только сетевые накладные расходы. Даже если один круг между приложением и базой занимает всего 5 миллисекунд, 50 000 вызовов дадут 250 секунд - 4 минуты 10 секунд. И это без времени на сам поиск, блокировки, преобразование данных и выполнение остального кода. При задержке 20 миллисекунд получится уже 16 минут 40 секунд.
Именно поэтому обработка может быстро работать на сервере разработчика и внезапно «умирать» между площадками или при удаленном расположении СУБД.
Нормальный вариант обычно такой: собрать уникальные наименования, одним запросом получить все соответствия, положить их в Соответствие и дальше работать в памяти. Если из 50 000 строк уникальных наименований 8 000, мы выполняем один запрос по набору вместо 50 000 отдельных обращений.
То же относится к чтению регистра сведений, поиску характеристики и проверке остатков. Маленький запрос внутри большого цикла редко остается маленькой проблемой.
7. ПОДОБНО по большой таблице
Пользователь хочет найти «подшипник» в любом месте наименования. Разработчик пишет:
ГДЕ
Номенклатура.Наименование ПОДОБНО &Шаблон
Если шаблон начинается с процента - «%подшипник%» - индекс по наименованию всего не помогает. СУБД приходится сканировать множество строк.
Отдельная история - живой поиск после каждого нажатия клавиши. Пользователь набрал десять символов, форма отправила до десяти запросов. Пять пользователей одновременно - уже до пятидесяти поисков, причем девять из десяти результатов каждому из них не нужны: человек продолжал печатать.
Иногда достаточно задержки в 300-500 миллисекунд перед запуском поиска и отмены предыдущего задания. Иногда можно искать только с начала строки. Для действительно большого каталога нужен отдельный поисковый механизм.
Здесь нет универсального рецепта. Но есть правило: ПОДОБНО с процентом в начале по многомиллионной таблице нельзя оставлять без замера только потому, что пользователю удобно.
Если же подобно используется для отбора данных в запросе, стоит найти альтернативные критерии поиска. Возможно, хорошим решением будет использование нового реквизита, по которому можно будет делать отбор по нужным критериям (и он будет содержать какой-то ссылочный тип данных).
8. Дополнительные свойства стали основной моделью данных
Механизм дополнительных реквизитов очень удобен. Я сам его использую. Проблема начинается, когда в дополнительном свойстве хранится признак, по которому каждый день строятся массовые отчеты и соединяются большие наборы данных.
Один из реальных примеров - платежный агент «Монета». Чтобы определить нужный сценарий возврата, отчету приходилось искать значение дополнительного свойства у документов, работать с составным типом и соединять это с финансовыми данными. Изначально доработка выглядела экономной: не меняем структуру документа, просто добавляем свойство. Через несколько лет за эту экономию платил каждый запуск отчета.
Причем такие решения опасны не только скоростью. В том же классе задач легко потерять ограничение по периоду или получить несколько значений свойства на один объект. Запрос остается синтаксически правильным, но начинает размножать строки или смешивать данные разных периодов.
Если признак участвует в ключевой логике, массовых отборах и соединениях, я перестаю считать его «дополнительным». Для него нужен явный реквизит или отдельный регистр сведений с нормальным типом и индексами.
Да, придется перенести историю и какое-то время контролировать заполнение старого и нового источника. Но это разовая сложность. Тяжелый запрос будет выполняться каждый день.
Это, пожалуй, самая архитектурно коварная причина из всего списка, потому что сама по себе она не похожа на ошибку — использование подсистемы «Дополнительные реквизиты и сведения» абсолютно легитимно и активно рекомендуется методологией 1С для расширения объектов без изменения конфигурации. Проблема начинается там, где через этот универсальный механизм начинают строить бизнес-логику, требующую соединений по ключевым параметрам.
9. Тяжелая операция выполняется на клиенте
Этот случай запомнился мне хорошо. Операция формировала этикетку, сохраняла ее в PDF и делала значительную часть работы на клиенте. Данные несколько раз ходили между клиентом и сервером, а пользователь все это время смотрел на зависшую форму.
После переноса основного алгоритма на сервер операция ускорилась примерно в десять раз.
Здесь важно, что ускорение дал не магический атрибут &НаСервере. Я сократил переключения контекста, перестал гонять лишние данные и выполнили тяжелую часть ближе к источнику. Если просто перенести на сервер плохой цикл, он останется плохим циклом, только теперь будет мешать всем пользователям.
Общее правило, которое стоит держать в голове: любая операция, интенсивно работающая с данными базы или требующая многократных обращений сервер-клиент-сервер, должна по умолчанию проектироваться как серверная процедура. Клиентский код должен заниматься тем, для чего он предназначен, — взаимодействием с пользователем, а не тяжёлыми вычислениями и формированием документов.
10. Транзакция открывается слишком рано
Вот типичная последовательность:
- начать транзакцию;
- прочитать и проверить большой набор данных;
- сформировать движения;
- выполнить несколько запросов;
- записать результат;
- зафиксировать транзакцию.
Блокировки удерживаются со второго шага, хотя реально изменять данные мы начинаем только на пятом. Если проверка занимает 40 секунд, все эти 40 секунд соседние процессы могут ждать.
Я стараюсь вынести из транзакции все, что не обязано быть внутри нее: подготовку параметров, чтение справочной информации, формирование файла, долгие расчеты, обращения к внешним сервисам. В транзакции остается короткий участок, где действительно нужна атомарность.
Особенно опасны внешние HTTP-вызовы внутри транзакции. Внешний сервис задумался на две минуты - и две минуты мы держим блокировки в 1С. Это не теория, такие конструкции встречаются.
11. Взаимоблокировки лечат повтором, а не причиной
Deadlock часто воспринимают как случайность: «два процесса неудачно совпали, давайте повторим». Повтор действительно может пройти. Но если порядок работы с ресурсами не изменился, ошибка вернется.
Простейшая схема:
- процесс А сначала изменяет складские данные, потом взаиморасчеты;
- процесс Б сначала изменяет взаиморасчеты, потом складские данные;
- каждый удерживает то, что нужно другому.
СУБД выбирает жертву и завершает один процесс. Если регламентное задание автоматически начинает все сначала, пользователи видят не одну ошибку, а дополнительную нагрузку от повторного выполнения.
У этого пункта нет красивого общего исправления. Нужно смотреть конкретный случай взаимоблокировки: какие запросы участвовали, в каком порядке брались ресурсы, почему операция не успела завершиться раньше. Иногда помогает единый порядок записи, иногда индекс, иногда уменьшение транзакции.
12. Сотни тысяч изменений в одной транзакции
Разработчику приятно сделать обработку атомарной: либо загрузили все 100 000 строк, либо не загрузили ничего. С точки зрения поддержки это тоже удобно - одна кнопка, один результат.
Но цена большой транзакции растет по мере выполнения. Накапливаются блокировки, увеличивается журнал, откат становится дорогим. Ошибка на строке 99 900 заставляет отменять почти всю работу.
Решение — разбивать массовую обработку на пакеты разумного размера (конкретный размер пакета зависит от специфики данных и обычно подбирается экспериментально — где-то это сотня записей, где-то несколько тысяч), каждый из которых оборачивается в собственную, короткую транзакцию.
Да, это чуть усложняет обработку ошибок — нужно продумать, что происходит, если пакет номер 47 из 100 упал с ошибкой, и предусмотреть журналирование прогресса. Но выигрыш в том, что блокировки удерживаются короткими всплесками, а не одним долгим периодом, и параллельные процессы получают шанс выполниться между пакетами, а не ждать полного завершения всей операции.
13. Длительная очередь обрабатывается одним потоком
Последний пункт не про ускорение одного запроса, а про общее время процесса.
Представим очередь из 12 000 документов. В среднем один документ проводится две секунды. Один последовательный поток потратит около 24 000 секунд - 6 часов 40 минут. Четыре независимых потока теоретически сократят время до 1 часа 40 минут. В реальности будет больше из-за конкуренции и накладных расходов, но порядок цифр понятен.
Главная ошибка - увидеть этот расчет и сразу запустить двадцать фоновых заданий. Если документы изменяют общие остатки или одни и те же последовательности, параллельные потоки начнут мешать друг другу. Вместо ускорения появятся ожидания и deadlock.
Распараллеливание работает, когда данные можно честно разделить: по организациям, складам, независимым очередям, диапазонам идентификаторов. Нужен лимит исполнителей и механизм возврата задания в очередь после ошибки.
В задачах с отложенным проведением вопрос «сколько потоков выдержит сервер?» обычно задают слишком рано. Сначала надо выяснить, какие документы не пересекаются по данным. После этого количество исполнителей уже определяется замерами.
Вместо вывода
У медленной работы 1С почти никогда нет одной общей причины. Есть конкретная операция и конкретное место, где расходуется время: чтение лишних данных, тысячи обращений к базе, клиент-серверные вызовы, ожидание блокировки, длинная транзакция, перегруженный диск или последовательная очередь.
Хорошая новость в том, что все это измеряется. Не всегда быстро, не всегда одним инструментом, но измеряется.
В следующих статьях я хочу разбирать отдельные случаи уже глубже: с фрагментами запросов, планами выполнения и последовательностью замеров.
Вступайте в нашу телеграмм-группу Инфостарт