1С:Управление торговлей зависает при закрытии дня: как это решили за неделю

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

первый звонок: отчёт по остаткам не открывается

Заявка в поддержку пришла в 9:14 утра: у оптовой компании стройматериалов на 35 менеджеров в 1С:Управление торговлей 11.4 отчёт «Остатки и доступность» висел третью минуту, а документы «Реализация товаров» проводились с задержкой. Через полчаса пожаловались ещё восемь человек — ровно те, кто в это время открывает утренние заказы с Ozon и Wildberries.

Картина повторялась каждый будний день с одной и той же точностью: 9:00–9:30 — пик жалоб, к обеду всё работает как обычно. Служба поддержки клиента сначала грешила на саму конфигурацию УТ и собиралась заказывать доработку отчёта у программиста-фрилансера — благо, платить за час работы дешевле, чем разбираться с сервером.

что показала диагностика: дело не в конфигурации

Сервер 1С стоял в серверной компании на одной машине с файловым хранилищем и бухгалтерской базой: восемь гигабайт оперативной памяти на СУБД, обычные HDD без запаса под нагрузку записи, четыре ядра на троих потребителей. Ночью с 3:00 до 6:00 шла синхронизация остатков с Ozon и Wildberries — тысячи записей в регистры одновременно с фоновым резервным копированием файлового сервера.

что показал журнал блокировок

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

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

почему обновление конфигурации ничего бы не изменило

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

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

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

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

три варианта, которые взвесила компания

Директор рассматривал три пути и попросил показать разницу в деньгах и рисках, а не в мегагерцах.

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

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

как прошёл перенос базы: по шагам

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

1. ✓Сняли контрольную выгрузку базы и сверили объём регистров с ночной синхронизацией маркетплейсов.
2. ✓Развернули тестовую копию на новом сервере и прогнали проведение документов за прошлый месяц, чтобы сравнить время до и после на одинаковом наборе данных.
3. ✓Перенесли лицензии и настроили регламентные задания обмена с Ozon и Wildberries на новом расписании, сдвинув самую тяжёлую синхронизацию на более раннее время.
4. ✓Сверили остатки построчно между старой и новой базой перед переключением пользователей.
5. ✓Переключили менеджеров на новый адрес сервера одним рабочим утром, старую машину оставили в резерве на неделю на случай отката.

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

что изменилось через две недели после переезда

Отчёт «Остатки и доступность» стал открываться за секунды вместо минут. Утренние 9:00–9:30 перестали быть точкой сбоя: документы проводятся без очереди, потому что ночная синхронизация маркетплейсов больше не делит диск с дневной работой пользователей. Заказы Ozon и Wildberries подтверждаются в отведённое площадкой время, а не с опозданием, и жалобы в чат поддержки по утрам прекратились.

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

как понять, что вам тоже пора менять сервер

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

• ✓отчёты и обработки тормозят в одно и то же время суток, а не хаотично;
• ✓на сервере одновременно живут файловое хранилище, почта или другая база 1С;
• ✓ночью идёт синхронизация с маркетплейсами или интернет-магазином, а утром база «просыпается» медленно;
• ✓диски в сервере — обычные HDD, а не SSD, и это не проверялось ни разу с момента покупки;
• ✓число пользователей выросло за последний год, а конфигурация сервера осталась прежней.

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

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

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

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

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

Нужно ли останавливать работу менеджеров на время переноса базы?

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

Чем выделенный сервер отличается от виртуального для 1С:Управление торговлей?

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

Как проверить, что дело именно в сервере, а не в самой конфигурации УТ?

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

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

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