Когда 1С начинает тормозить из-за роста нагрузки

Производительность как задача системной диагностики

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

Главная инженерная задача — определить, какой механизм ограничивает производительность, почему это ограничение проявляется при текущей нагрузке и какое изменение устранит его без нарушения корректности бизнес-процессов.

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

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

Почему рост нагрузки обнаруживает ограничения, незаметные раньше

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

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

Эти изменения неравнозначны.

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

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

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

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

Четыре механизма деградации

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

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

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

Как определить, где именно теряется время

Пользователь воспринимает 1С как единую систему. Инженер должен рассматривать её как цепочку взаимодействующих компонентов.

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

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

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

Поэтому для эффективной оптимизации необходимо точно локализовать узкое место в этой цепочке.

Разделение времени выполнения и времени ожидания

Для расследования особенно важно отличать активную работу от ожидания.

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

Документация: Microsoft Learn — Troubleshoot slow-running queries in SQL Server.

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

Почему небольшое увеличение нагрузки иногда приводит к резкому замедлению

Одна из наиболее важных причин деградации — приближение ограниченного ресурса к насыщению.

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

Если обслуживание занимает в среднем 100 мс, получаем следующие значения:

При росте загрузки с 90 до 95% среднее время в системе удваивается, хотя само время обслуживания не изменилось.

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

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

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

Блокировки в 1С: почему один процесс может задерживать другие

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

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

Если транзакция A выполняет дополнительную работу, пока удерживает блокировку, транзакция B может ожидать несколько секунд, даже если её собственная полезная работа занимает доли секунды.

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

Управляемые блокировки платформы и блокировки СУБД

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

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

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

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

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

Правильный результат — не отсутствие блокировок как таковых, а корректная работа системы при приемлемом уровне конкуренции.

Запросы и прикладной код: как локальная неэффективность становится системной

Неоптимальные запросы — один из распространённых источников деградации. Но инженер должен исследовать не только время одного запроса, а полную стоимость алгоритма.

Есть два принципиально разных сценария.

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

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

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

Сценарий B. Запрос выполняется слишком часто

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

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

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

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

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

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

Для Microsoft SQL Server полезным инструментом является Query Store. Он позволяет изучать историю запросов, планов выполнения и статистики, а также искать регрессии производительности после изменения плана.

Документация: Monitor performance by using the Query Store.

Для других СУБД следует использовать соответствующие средства диагностики. Наличие Query Store нельзя считать универсальным решением для любой базы 1С.

Мониторинг планов выполнения в динамике — обязательная часть инженерного контроля СУБД.

Фоновые задания и интеграции: как создаётся скрытая конкуренция

В корпоративной системе пользовательская работа выполняется одновременно с фоновыми задачами.

Это могут быть расчёты, регламентные операции, обмены с внешними системами, обработка очередей, массовое проведение документов и резервное копирование.

Каждый процесс по отдельности может работать нормально. Проблема появляется, когда несколько тяжёлых задач совпадают по времени или обращаются к общим данным.

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

В зависимости от реализации фоновые задачи могут конкурировать за CPU, дисковый ввод-вывод, ресурсы СУБД и общие данные. Некоторые из них могут создавать блокировки, другие — насыщать инфраструктуру, третьи — увеличивать очередь операций.

Оптимизация расписания и разделение потоков данных — базовый шаг к устранению скрытых конфликтов.

Почему перенос заданий на ночь не всегда решает проблему

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

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

Механический сдвиг регламентов по времени — временная полумера при системных проблемах масштабирования.

Рост базы данных: где заканчивается проблема объёма и начинается проблема архитектуры

Размер информационной базы — слабый самостоятельный индикатор производительности.

Ключевая задача — изолировать оперативные вычисления от накопленной исторической массы.

Индексы — инструмент, а не универсальное лекарство

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

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

Архивирование не заменяет оптимизацию

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

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

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

Оптимальная архитектура данных всегда строится на балансе стоимости дискового хранения и стоимости оперативного доступа.

Когда проблема действительно в инфраструктуре

Неактивный код и блокировки — не единственные возможные причины. Недостаточная производительность оборудования тоже может ограничивать систему.

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

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

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

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

Инфраструктура должна следовать за оптимизацией алгоритмов, а не маскировать их неэффективность.

Как расследовать замедление 1С на практике

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

Этап 1. Описать симптом в терминах бизнес-процесса

Недостаточно записать «1С тормозит».

Такое описание уже задаёт направление исследования.

Этап 2. Построить базовую линию

Для критичных операций фиксируют:

Среднего времени недостаточно. Если медиана составляет 2 секунды, а p95 — 20 секунд, проблема может проявляться только в определённых сценариях или при конкуренции.

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

Без точной базовой линии невозможно достоверно доказать успешность проведённой оптимизации.

Этап 3. Собрать технические данные

Для диагностики 1С могут использоваться:

Инструмент выбирают под конкретную гипотезу.

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

В технологическом журнале 1С используются события, соответствующие разным классам операций. Для расследования блокировок могут потребоваться события TLOCK, TTIMEOUT и TDEADLOCK, а для анализа запросов — соответствующие события взаимодействия с СУБД, в зависимости от конфигурации сбора и используемой СУБД.

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

Сбор данных необходимо настраивать аккурасно. Избыточное журналирование увеличивает объём записей и усложняет анализ, а неправильно настроенный фильтр может не зафиксировать нужные события. Перед расследованием следует проверить, что журнал действительно собирает ожидаемую информацию.

Этап 4. Сформировать конкурирующие гипотезы

Допустим, проведение документа стало занимать 15 секунд вместо 3. Вместо немедленного изменения настроек сервера формируются несколько гипотез:

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

Этап 5. Подтвердить первопричину

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

Только после этого можно выбирать исправление.

Этап 6. Проверить изменение в сопоставимых условиях

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

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

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

Успешная оптимизация подтверждается отсутствием регрессии в смежных бизнес-процессах.

Этап 7. Закрепить результат мониторингом

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

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

Экономика производительности: как оценить последствия для предприятия

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

Это не означает автоматически потерю 110 продуктивных человеко-часов. Сотрудники могут выполнять другие задачи во время ожидания, а часть задержек может перекрываться. Расчёт показывает верхнюю оценку времени ожидания, которое стоит исследовать, а не готовую сумму убытков.

Для оценки экономического эффекта необходимо выяснить:

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

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

Экономическая целесообразность — финальный критерий при планировании архитектурных изменений.

Как понять, что локальной оптимизации недостаточно

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

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

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

Точки сериализации

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

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

Когда оправдано разделение контуров

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

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

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

Разделение контуров — это компромисс между скоростью отклика интерфейсов и актуальностью единого аналитического пространства.

Как проверить готовность системы к дальнейшему росту

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

Для этого нужен набор измеримых показателей.

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

Нагрузочное тестирование

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

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

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

Практический план: что делать, если 1С уже тормозит

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

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

Заключение

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

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

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

Зрелое управление производительностью 1С — это не постоянное увеличение ресурсов и не бесконечная оптимизация отдельных запросов. Это системная работа по выявлению ограничения, проверке причин и сохранению устойчивости под реальной нагрузкой.

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

🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.

Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).