42 пользователя, зависшая форма: как найти, почему тормозит 1С

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

42 пользователя, зависшая форма: с чего начинается разбор

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

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

Шаг 1. Железо: сколько памяти держат процессы rphost

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

• ✓рост числа пользователей за последний год не сопровождался апгрейдом сервера;
• ✓зависания появляются пачкой в одно и то же время — когда сессий максимум;
• ✓на других серверах в той же сети всё работает нормально, узкое место конкретно у 1С.

Чем именно смотреть, без специального софта

На Windows-сервере достаточно диспетчера задач или perfmon: колонка «Память» по процессам rphost.exe и счётчик Processor Queue Length покажут очередь на CPU. На Linux-хостах с сервером 1С поднимают top или htop в момент зависания и смотрят те же метрики: % CPU, резидентную память, значение load average относительно числа ядер. Если load average стабильно выше числа ядер именно в часы пиковой нагрузки — процессор упирается в лимит, а не «подтормаживает».

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

Шаг 2. Блокировки СУБД и регламентные задания среди дня

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

Проверяется это через журнал регистрации 1С и монитор активных соединений СУБД: для MS SQL Server — процедура sp_who2 или представление sys.dm_exec_requests, для PostgreSQL — запрос к pg_stat_activity с фильтром по wait_event. Если в момент зависания там висит одна долгая транзакция, а остальные сессии ждут именно её — дело в расписании регламентных операций, а не в мощности сервера. Правильная настройка сервера 1С — перенос тяжёлых регламентных операций на ночь и разведение потоков по разным рабочим процессам — снимает эту причину без единого рубля в новое оборудование.

Шаг 3. Код конфигурации, тяжёлые отчёты и тест Гилёва

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

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

Причина, которую часто пропускают: общий сервер и «шумные соседи»

Отдельная история — когда база стоит на дешёвом общем хостинге, а не на выделенных ресурсах. Тогда сервер может тормозить не из-за собственной нагрузки, а из-за соседних виртуальных машин на том же физическом узле: чья-то тяжёлая база начинает резервное копирование, и процессор вашей 1С получает меньше тактов, хотя сама она в этот момент делает ровно то же самое, что и всегда. Отличить это от собственных проблем помогает метрика CPU steal time — в Linux она видна в top как столбец %st: если она регулярно скачет вверх без видимой причины на вашей стороне, ресурсы делит с кем-то ещё. Тормоза при этом непредсказуемы по времени, в отличие от регламентных блокировок из шага 2, которые повторяются строго по расписанию. Единственное системное решение здесь — гарантированные, а не разделяемые с другими клиентами ресурсы: виртуальный сервер для 1С с закреплённым CPU и памятью либо отдельная физическая машина под задачу. На практике этот пункт всплывает чаще, чем кажется: компания переносит базу с офисного сервера на облачный, ждёт ускорения — а получает те же зависания, потому что попала на тарифный план с общими, а не гарантированными ресурсами.

Три варианта, если разбор упёрся в железо

Когда шаги 1–4 указывают на нехватку или дележ ресурсов, а не на код или расписание, у бизнеса на деле три варианта решения — разного масштаба по деньгам и срокам.

Для базы с несколькими юрлицами и объёмным документооборотом отдельно стоит смотреть сервер под 1С:ERP — под неё нужен другой запас по CPU и диску, чем под обычную бухгалтерию на 10–15 пользователей.

Как перенос сервера закрывает вопрос за один-два дня

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

Дальше сервер обслуживается не как разовая покупка железа, а как услуга с понятной стоимостью: аренда сервера под 1С — от 1 100 ₽/мес за пользователя, а сопровождение и работа сисадмина при необходимости — от 3800 руб/час, без затрат на закупку, монтаж и последующий апгрейд оборудования каждые несколько лет. И главное — без повторного разбора «почему опять тормозит» через год, когда база снова подрастёт.

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

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

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

Поможет ли просто добавить оперативной памяти в текущий сервер?

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

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

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

Может тормозить не сервер, а интернет-канал или клиентские компьютеры?

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

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

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