Встретились с ситуацией, когда типовой документ, например "Реализация товаров и услуг", в клиент-серверной базе "1С:Бухгалтерия 3.0" начал проводиться недопустимо долго — 10, 20 секунд и более? А в моменты пиковой нагрузки пользователи стали получать ошибки о конфликте блокировок? Это распространенная проблема, которая может быть вызвана целым комплексом причин. Давайте вместе разберемся, как провести диагностику и вернуть системе былую производительность.
Проанализируем ситуацию по шагам: от выявления возможных причин до нахождения конкретного "узкого места" и его устранения.
Прежде чем погружаться в код и настройки, определим круг основных "подозреваемых", которые часто вызывают подобные проблемы:
Гадать о причинах можно долго, но самый эффективный способ — использовать встроенный инструмент платформы 1С. "Замер производительности" точно покажет, на выполнение какой строки кода уходит львиная доля времени.
Рассмотрим, как его использовать:
В нашем случае анализ показал, что почти 50% времени выполнения уходит на одну строку кода в общем модуле ДатыЗапретаИзмененияСлужебный:
РезультатыЗапроса = Запрос.ВыполнитьПакет();
Это однозначно указывает на то, что "узким местом" является механизм проверки даты запрета изменений. Каждый раз при проведении документа система выполняет сложный запрос, чтобы проверить, разрешено ли пользователю изменять данные в этом периоде. Именно этот запрос по какой-то причине выполняется очень долго.
Теперь, когда мы знаем врага в лицо, у нас есть два основных пути решения проблемы: быстрая проверка гипотезы и системное решение на уровне базы данных.
Чтобы на 100% убедиться, что проблема именно в дате запрета, проведем эксперимент. Временно отключим эту проверку для одного пользователя и посмотрим на результат. Важно: это не решение проблемы, а лишь диагностический шаг!
Если после этого документ стал проводиться значительно быстрее (например, за 1-2 секунды вместо 15), наш диагноз подтвердился. Теперь можно включать дату запрета обратно и переходить к полноценному решению.
Долгий запрос к датам запрета почти всегда является следствием проблем с обслуживанием базы данных на сервере SQL. Для исправления ситуации необходимо выполнить регламентные операции. Эту задачу лучше поручить системному администратору или специалисту по SQL.
Ключевые операции по обслуживанию:
Настоятельно рекомендуется не выполнять эти операции вручную, а настроить автоматический план обслуживания (Maintenance Plan) на SQL Server, который будет регулярно (например, каждую ночь) выполнять эти и другие важные действия (проверка целостности, резервное копирование). Правильно настроенное обслуживание — залог стабильной и быстрой работы 1С в клиент-серверном варианте.
В ходе анализа часто возникает вопрос о параметре Время ожидания блокировки данных, который по умолчанию равен 20 секундам. Это то время, которое система готова ждать, пока занятый другим процессом ресурс (например, таблица регистра) освободится. Если за 20 секунд ресурс не освободился, пользователь получает ошибку о превышении времени ожидания.
Возникает соблазн просто увеличить это значение, например, до 30 или 60 секунд. Делать этого не стоит!
Почему это плохая идея:
Правильный путь — не увеличивать время ожидания, а уменьшать время выполнения операций и минимизировать вероятность самих блокировок.
Вернемся к одной из первоначальных гипотез. Даже если вы оптимизировали запрос даты запрета, частые обмены данными все равно могут вызывать конфликты блокировок. Проанализируйте расписание регламентных и фоновых заданий.
Снизив частоту фоновых заданий, вы уменьшите количество транзакций, конкурирующих с действиями пользователей, и, как следствие, снизите вероятность возникновения блокировок.
Таким образом, решив проблему с производительностью запроса даты запрета через обслуживание SQL и оптимизировав расписание обменов, вы сможете вернуть системе отзывчивость и избавиться от назойливых ошибок блокировок.