Каждый администратор крупных баз данных «1С:Предприятие» рано или поздно сталкивается с мистическими ситуациями. Представьте сценарий: абсолютно типовой, годами проверенный код, который успешно работает у сотен пользователей, в разгар рабочего дня начинает «сыпать» непонятными синтаксическими ошибками. Платформа внезапно сообщает, что базовые системные типы данных не определены. Чаще всего сбои происходят при инициализации таких объектов, как ТабличныйДокумент, СхемаКомпоновкиДанных или ZipФайл. При этом обычная перезагрузка сервера временно решает проблему на 1–2 дня, после чего симптомы возвращаются.
В этой статье мы подробно разберем, почему возникает эта проблема, проанализируем неочевидные системные взаимосвязи и выработаем комплексный план устранения неполадок, чтобы раз и навсегда избавить сервер от подобных сбоев.
Для начала разберем по шагам физику процесса. Ошибка вида Тип не определен ТабДок = Новый <<>>ТабличныйДокумент выглядит как ошибка компиляции или синтаксический бред. Однако на самом деле это замаскированное проявление нехватки оперативной памяти или сбоя адресного пространства рабочего процесса сервера 1С — rphost.exe.
Когда пользователь запускает формирование тяжелого отчета, выгрузку данных или формирование печатной формы, серверное приложение должно выделить память под создание соответствующего объекта. Если в этот момент рабочий процесс rphost.exe исчерпал лимиты выделенной ему памяти (что особенно критично для 32-разрядных версий сервера 1С, где жесткий лимит на один процесс составляет всего 2 ГБ), встроенный компилятор платформы не может инициализировать системный класс. Вместо корректного системного исключения «Out of Memory» (Недостаточно памяти), платформа 1С на старых релизах (особенно ветки 8.3.7) выдает ложное сообщение о том, что тип объекта не определен.
Рассмотрим подробнее пять основных векторов решения этой проблемы: от оптимизации распределения памяти до устранения аппаратных сбоев сетевой подсистемы.
Если на вашем предприятии до сих пор используется 32-битный сервер приложений 1С, это является главным узким местом системы. В условиях роста базы данных (в рассматриваемом случае объем превышает 33 ГБ) и при пиковых нагрузках рабочие процессы неизбежно будут упираться в лимит адресного пространства в 2 ГБ.
Переход на 64-разрядную версию сервера кардинально решает проблему фрагментации виртуальной памяти. Процессы rphost.exe архитектуры x64 способны адресовать практически неограниченный объем оперативной памяти, что полностью исключает возникновение ошибок инициализации типов из-за локального дефицита ОЗУ.
Если оперативный переход на 64-разрядную платформу невозможен, или если утечки памяти продолжают нагружать сервер x64, необходимо отказаться от практики ручной перезагрузки всего сервера ОС Windows. Платформа «1С:Предприятие» обладает встроенным механизмом автоматического и бесшовного перезапуска (рециклинга) «протекших» рабочих процессов.
Настроим параметры перезапуска рабочих процессов через утилиту «Администрирование серверов 1С Предприятия». Проанализируем ключевые параметры, которые необходимо задать в свойствах вашего локального кластера:
1500000 KB (около 1.5 ГБ), для 64-битных систем — ориентировочно 4000000 KB (4 ГБ) или исходя из общего объема установленной ОЗУ.20–30 секунд.180 до 300 секунд) старый процесс не принимает новые соединения, плавно передает активные сеансы новому процессу rphost.exe, завершает текущие вызовы и затем безопасно закрывается.25–30 соединений). Это позволит распределить нагрузку равномерно по нескольким процессам rphost.exe.Еще одна неочевидная, но крайне распространенная на практике причина — сбои в сетевой подсистеме на уровне взаимодействия между сервером приложений 1С и СУБД MS SQL Server. Если эти службы установлены на разных физических серверах (или внутри разных виртуальных машин), сетевые пакеты с сериализованными объектами метаданных могут искажаться при передаче.
Это происходит из-за некорректной работы драйверов сетевых плат при включенных технологиях аппаратного ускорения передачи данных (так называемого «оффлоадинга»). В результате пакет данных доходит до сервера приложений поврежденным, из-за чего платформа не может корректно прочитать структуру метаданных класса и выдает ошибку неопределенного типа.
Разберем по шагам, как отключить данные функции на сервере под управлением Windows Server 2012 R2:
IPv4 Checksum Offload (Разгрузка контрольной суммы IPv4)Large Send Offload V2 (IPv4) (Большая отправка IPv2)TCP Connection Offload (IPv4) (Разгрузка соединений TCP)Дополнительно рекомендуется отключить глобальные параметры разгрузки TCP в самой операционной системе через командную строку, запущенную от имени администратора:
netsh int tcp set global chimney=disabled
netsh int tcp set global autotuninglevel=disabled
При формировании табличных документов, отчетов СКД и сжатии файлов во временные папки операционной системы записываются сотни мегабайт промежуточных данных. Серверная служба 1С работает под определенной учетной записью (часто это USR1CV8 или локальная система SYSTEM).
Со временем каталог временных файлов этой учетной записи переполняется миллионами файлов с префиксами вида v8_XXXX. Файловая система NTFS начинает испытывать проблемы с адресацией и скоростью создания новых файлов в одной директории, из-за чего методы Новый ТабличныйДокумент или Новый ZipФайл завершаются системным отказом.
Для решения этой проблемы настроим регулярную регламентную очистку временных файлов. Выполнять её лучше всего ночью, предварительно остановив службу сервера «1С:Предприятие». Ниже приведен пример простого командного сценария (BAT-файла), который можно добавить в планировщик задач Windows:
net stop "1C:Enterprise 8.3 Server Agent"
timeout /t 20
del /q /f /s "C:\Users\USR1CV8\AppData\Local\Temp\*"
for /d %%p in ("C:\Users\USR1CV8\AppData\Local\Temp\*") do rmdir "%%p" /s /q
net start "1C:Enterprise 8.3 Server Agent"
Этот скрипт безопасно остановит службу, полностью очистит структуру временных папок пользователя USR1CV8 и запустит службу обратно.
Иногда плавающая ошибка инициализации типов провоцируется некорректным контекстом выполнения кода. Например, если внешнее приложение подключается к вашей базе данных через механизм COM-соединения (используя V83.COMConnector), или если регламентное задание выполняется на сервере без создания полноценного клиентского сеанса.
В таких случаях компилятор на сервере может не обладать информацией о типах, которые по умолчанию доступны только в контексте тонкого или толстого клиента. Проанализируем проблемный участок кода. Если создание объекта происходит в общем модуле, убедитесь, что у модуля установлены правильные флаги компиляции (флаг Сервер должен быть включен, а вызовы клиентских процедур должны быть изолированы директивами компиляции).
Используйте безопасную инициализацию объектов с проверкой доступности контекста или предварительной проверкой типа, как показано в примере ниже:
#Если Сервер Или ТолстыйКлиентОбычноеПриложение Тогда
Попытка
ТабДок = Новый ТабличныйДокумент;
Исключение
ЗаписьЖурналаРегистрации("СбойИнициализации",
УровеньЖурналаРегистрации.Ошибка, , ,
"Не удалось создать ТабличныйДокумент: " + ОписаниеОшибки());
ВызватьИсключение;
КонецПопытки;
#КонецЕсли
Плавающие ошибки «Тип не определен» — это классический маркер системных проблем инфраструктуры, а не ошибок в кодовой базе конфигурации. Выполнение предложенного комплекса мер — переход на платформу x64, настройка рециклинга рабочих процессов, отключение сетевого оффлоадинга и регулярная очистка кэша и временных файлов — гарантированно стабилизирует работу серверного кластера и избавит пользователей от внезапных сбоев в течение рабочего дня.