Почему зависает 1С:Медицина при формировании комплекта документов и как это исправить?

← На главную

Зависание системы в момент формирования тяжелых отчетов или комплектов документов — классическая проблема для высоконагруженных баз «1С:Медицина», работающих на связке с PostgreSQL. Ситуация осложняется тем, что ресурсы сервера (процессор и память) могут выглядеть свободными, но при этом служба «Агент сервера 1С» перестает отвечать на запросы. Разберем по шагам, почему это происходит и как стабилизировать работу системы.

Переход на 64-битную версию сервера 1С: обоснование необходимости

Проанализируем технические характеристики сервера автора: база данных объемом 27 Гб (в формате .dt) и использование 32-битного сервера 1С (x32). Это является критическим узлом. Рассмотрим подробнее, почему 32-битный сервер не справляется, даже если диспетчер задач показывает низкое потребление памяти.

Основная проблема заключается не в физической памяти, а в адресном пространстве. Процесс rphost.exe разрядности x32 ограничен 2-3 Гб адресного пространства. При формировании комплекта документов система создает множество временных таблиц и объектов в памяти. Если адресное пространство фрагментировано, процесс не может выделить непрерывный блок памяти для новой операции и «зависает» в ожидании или аварийно завершается. Для базы объемом 27 Гб (которая в развернутом виде в СУБД может занимать более 150 Гб) использование x32 сервера недопустимо.

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

Оптимизация настроек PostgreSQL для работы с большими объемами данных

Выясним причину возможных блокировок на уровне СУБД. При формировании комплекта документов 1С отправляет в PostgreSQL сложные запросы с множеством соединений. Стандартных настроек часто бывает недостаточно. Разберем параметры, которые необходимо скорректировать в postgresql.conf:

work_mem: Этот параметр определяет объем памяти для операций сортировки. В теме указано значение 128MB. Для тяжелых медицинских отчетов этого может быть мало. Попробуем увеличить его до 256MB или 512MB.
max_locks_per_transaction: По умолчанию значение равно 64. При формировании комплектов документов количество блокируемых объектов может превышать этот лимит. Рекомендуем установить значение 256 или 512.
temp_buffers: Установите значение не менее 64MB для эффективной работы с временными таблицами.

Для диагностики текущих блокировок, когда система уже зависла, выполним следующий запрос в консоли PostgreSQL:


SELECT 
    psa.query, 
    psa.datname, 
    psa.usename, 
    psa.state, 
    pl.mode, 
    pl.locktype 
FROM pg_locks pl 
LEFT JOIN pg_stat_activity psa ON pl.pid = psa.pid 
WHERE psa.state = 'active';

Этот запрос поможет нам увидеть, какой именно процесс «держит» таблицы и не дает остальным пользователям завершить формирование документов.

Отключение режима отладки (-debug)

Проанализируем влияние флага -debug. В сообщении упоминалось, что служба запущена с этим флагом. На рабочем сервере (Production) использование режима отладки крайне не рекомендуется. Этот режим заставляет сервер приложений передавать огромные массивы метаданных для конфигуратора, что создает избыточную нагрузку на сетевой стек и может приводить к взаимным блокировкам (deadlocks) процессов rphost.

Решение: отредактируйте реестр Windows или параметры запуска службы «Агент сервера 1С», удалив флаг -debug, и перезапустите сервер в нерабочее время.

Проблема драйверов печати и штрихкодирования

Рассмотрим ситуацию, когда зависание происходит именно в момент вывода документов на экран или принтер. 1С:Предприятие при формировании табличного документа (печатной формы) обращается к драйверу принтера по умолчанию для расчета параметров страницы (полей, разрывов). Если принтер сетевой и он недоступен, или драйвер работает некорректно, процесс формирования документа «засыпает» до получения ответа от службы печати Windows (Spooler).

Посмотрим, что можно сделать:

Установим на сервере виртуальный принтер (например, «Microsoft Print to PDF») и сделаем его принтером по умолчанию для пользователя, под которым запускается служба 1С.
Проверим используемую компоненту печати штрихкодов. Если используется старый ActiveX (1CBarCode.dll), попробуем обновить конфигурацию на использование нативных методов платформы 1С по генерации штрихкодов, которые не зависят от внешних библиотек.

Внешние факторы и техническое обслуживание базы

Выясним причину ошибки СУБД «Файл не найден», упомянутой автором. Это может указывать на физическое повреждение индексов или проблемы с дисковой подсистемой. Разберем шаги по технической профилактике:

Реиндексация: Выполним полную реиндексацию базы данных через консоль PostgreSQL: REINDEX DATABASE имя_вашей_базы;.
Исключения антивируса: Убедимся, что папки данных PostgreSQL и каталоги сеансов 1С (snccntx) добавлены в исключения антивирусного ПО. Антивирус может блокировать временные файлы 1С в момент их интенсивного создания.
Проверка оборудования: Проанализируем системный журнал Windows (Event Viewer) на наличие ошибок disk или ntfs. Если SSD-накопитель имеет битые сектора, запись временных данных будет вызывать системные прерывания, приводящие к «мертвому» зависанию процессов.

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