блокировки в 1С: код виноват или сервер не тянет

если блокировка держится секунды и снимается сама — виноват код (длинная транзакция, неудачный индекс). если блокировка растёт часами и не снимается даже без пользователей — упирается в железо сервера: диск, память, число ядер СУБД. отличить одно от другого можно по логу технологического журнала за 10 минут, не трогая конфигурацию.

🔍 сцена: понедельник, 9:05, отчёт не открывается

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

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

📋 чек-лист: 6 признаков, которые разводят код и сервер

• ✓блокировка снимается за секунды сама по себе, но повторяется каждый час в одно и то же время — почти всегда код: длинная транзакция в обработке проведения или обмене данными.
• ✓блокировка держится минутами и не снимается, пока не убьёшь сеанс вручную — часто взаимная блокировка (deadlock) в коде, а не нагрузка на сервер.
• ✓в диспетчере задач сервера 1С или СУБД загрузка процессора стабильно ниже 30%, а очередь блокировок растёт — код, не железо: сервер простаивает, просто ждёт снятия блокировки другим процессом.
• ✓загрузка CPU или диска на сервере СУБД держится у 90-100% именно в момент блокировок — это сервер: ресурсов физически не хватает на параллельные операции.
• ✓время диска (Disk Queue Length или аналог в мониторинге хостинга) растёт вместе с ростом числа блокировок — узкое место в дисковой подсистеме, типичная картина на дешёвых виртуалках с общим HDD.
• ✓проблема появилась резко после роста числа пользователей или объёма базы, без изменений в коде — сервер перестал справляться с текущей конфигурацией по количеству ядер или памяти.

⚙️ как читать технологический журнал за 10 минут

что включить

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

на что смотреть

в TLOCK важны два поля: Context (какой код или объект вызвал блокировку) и Duration (сколько держалась). если Duration исчисляется миллисекундами, а Context каждый раз указывает на одну и ту же обработку или регистр — это код, конкретный участок и надо чинить транзакцию. если Duration растёт вместе с общей загрузкой сервера и Context каждый раз разный — дело не в конкретном фрагменте кода, а в том, что СУБД физически не успевает обрабатывать параллельные запросы.

отдельная проверка — тест Гилёва

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

💰 цена ошибки: что теряет бизнес, если путать причины

если гонять программиста переписывать код, когда проблема в железе, — заплатите за часы разработки (сопровождение 1С стоит от 3800 руб/час), а блокировки вернутся через месяц вместе с ростом базы. если наоборot покупать более мощный сервер, когда виноват один плохо написанный обмен с сайтом или маркетплейсом, — потратите бюджет на аренду, а конкретная транзакция как висела секундами, так и будет висеть на любом железе.

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

📊 сравнение: три сценария и что с ними делать

🖥️ что делать, если журнал показывает на сервер

когда TLOCK стабильно указывает на нехватку ресурсов, а не на код, дальше есть развилка: докупать железо в офис или переносить базу на арендованный сервер. второе быстрее — не нужно ждать поставку и настраивать RAID с нуля, конфигурация разворачивается на готовой инфраструктуре. у нас аренда сервера 1С начинается от 1 100 ₽/мес за пользователя, а параметры (число ядер, объём памяти, тип диска) подбираются под результат теста Гилёва и под конкретную конфигурацию — Бухгалтерию, УТ или ERP.

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

🔁 итог сценария с понедельником

в примере с закрытием месяца технологический журнал показал: CPU сервера СУБД держался на 95% ровно в момент запуска регламентного пересчёта итогов, Context в TLOCK был разным каждый раз. значит, дело не в конкретной строке кода, а в том, что сервер не тянул параллельную нагрузку 35 пользователей плюс фоновую задачу. перенос базы на арендованный сервер с большим числом ядер снял повторяемость проблемы — отчёт стал открываться за секунды вместо минут ожидания и таймаута.

❓ Частые вопросы

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

включите в техническом журнале события TLOCK и TTIMEOUT на 10-15 минут в момент проблемы. если Context каждый раз указывает на один и тот же код при низкой загрузке CPU — это код. если загрузка CPU или диска высокая и Context разный — упирается в сервер.

поможет ли просто перезагрузка сервера 1С при постоянных блокировках?

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

что показывает тест Гилёва и зачем он при разборе блокировок?

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

сколько стоит перенести базу 1С на арендованный сервер, если диагностика показала нехватку ресурсов?

аренда сервера 1С начинается от 1 100 ₽/мес за пользователя, конкретная конфигурация (ядра, память, диск) подбирается по результатам теста Гилёва под вашу базу и число пользователей.

может ли слабый сервер провоцировать блокировки, даже если код обмена написан правильно?

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