От экспертов «1С-Рарус»: Аварийное завершение рабочих процессов кластера «1С» и полнотекстовый поиск данных

Массовое зависание 1С:ERP у пользователей

Большое предприятие ведет сложный производственный учет в системе «1С:ERP Управление предприятием 2.4». Кластер серверов 1С:Предприятия состоит из 7 узлов, регламентные операции выполняются раз в сутки в течение двухчасового технологического окна. В системе работают более 500 пользователей во всех 11 часовых поясах России. В связи с этим, активная работа происходит практически в режиме 24/7.

В определенный период времени начинают проявляться проблемы массового зависания системы одновременно у всех работающих в программе пользователей. Периодичность таких зависаний со слов клиента не понятна, а предположения администраторов в том, что происходит либо падение рабочих процессов rphost либо падение менеджера кластера rmngr. Также, со слов клиента, проблем с памятью и другими частями ресурсов сервера нет. Из особенностей внедрения в базе присутствует большое количество подключаемых внешних отчетов и обработок, настроенных на запуск в фоновом режиме.

Инфраструктура исследуемой системы

• Операционная система Windows Server 2016.
• База данных Microsoft SQL Server 2016 64х.
• Версия сервера 1C: 8.3.16.1502.
• Виртуализация с 280 Гб выделенной оперативной памяти.
• 500+ пользователей работающих практически во всех подсистемах «1С:ERP Управление предприятием 2.4» за исключением зарплатного блока.

Проверяем rphost и rmngr

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

Файл logcfg.xml, который используется при настройке технологического журнала приведен ниже:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log history="72" location="e:\logs">
        <property name="all"/>
        <event>
        	<eq property="name" value="ATTN"/>
        </event>
        <event>
        	<eq property="name" value="CLSTR"/>
        </event>
        <event>
        	<eq property="name" value="CONN"/>
        </event>
        <event>
        	<eq property="name" value="EXCP"/>
        </event>
        <event>
        	<eq property="name" value="PROC"/>
        </event>
    </log>
</config> 

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

1. 19:54.878017-0,ATTN,2,process=ragent,OSThread=14268,Descr=Temporary allowed memory limit exceeded for server,ServerID=07d60d35-23a8-460a-b035-5ebda093b157,HostName=rarus,TotalMemory(Kb)=283114996,TempAllowedProcessesMemory(Kb)=0 (80% of TotalMemory),TempAllowedTimeLimit=300,ExcessStartTime=20200930101949,ExcessDuration(sec)=5,ProcessList[pid, mem(Kb)]='[26380, 185359256], [10480, 30839344], [22440, 21679216], [3352, 727288]'
19:54.894007-0,
2. 20:09.925019-0,ATTN,2,process=ragent,OSThread=14268,Descr=Critical memory limit exceeded for server,ServerID=07d60d35-23a8-460a-b035-5ebda093b157,HostName=rarus,TotalMemory(Kb)=283114996,CriticalProcessesMemory(Kb)=0 (95% of TotalMemory),ExcessStartTime=20200930101949,ExcessDuration(sec)=20,ProcessList[pid, mem(Kb)]='[26380, 223309276], [10480, 30441068], [22440, 21164932], [3352, 1234416], [21604, 92772]'
3. 20:14.941018-0,ATTN,2,process=ragent,OSThread=14268,Descr=Process exceeded critical memory limit,agentURL=tcp://ppl-1c-02:1540,procURL=tcp://rarus:1561,Pid=10480,Name=rphost
4. 20:14.941019-0,ATTN,2,process=ragent,OSThread=14268,Descr=Process will be killed,agentURL=tcp://ppl-1c-02:1540,procURL=tcp://rarus:1561,Pid=10480,Name=rphost,logOnly=0,createDump=0 

Система мониторинга кластера анализирует объем используемой памяти рабочих процессов и начинает завершение проблемных рабочих процессов в штатном режиме при достижении 80% от общего объема памяти, и в аварийном режиме если объем используемой памяти превысит 95%.

Немного теории:

Данные действия как раз фиксируются событиями ATTN, которые мы наблюдаем выше. Видим, что кластер серверов «1С» сначала зафиксировал объем использования оперативной памяти в 80% (событие 1) и начал завершение рабочих процессов в штатном режиме. Но уже через 15 секунд фиксируется следующее событие о том, что объем используемой памяти достиг 95% (событие 2). Это и приводит к аварийному завершению рабочих процессов кластера (события 3 и 4).

Несмотря на изначальные входные данные от клиента о том, что нет проблем с недостатком оперативной памяти и другими ресурсами сервера, видим значительное потребление памяти (более 280 Гб) рабочими процесса кластера серверов «1С».

Ищем причины большого потребления памяти

Следующим шагом будет выяснение причин такого поведения системы. Для полноты картины нам не хватает следующих данных:

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

Включим мониторинг ресурсов системы в Windows при помощи утилиты Performance monitor. Создадим группу сборщиков данных и добавим в нее счетчик «Байт виртуальной памяти» по всем процессам, а также с детализацией по процессам «1С» в системе. Для этого сначала выбираем счетчик в списке по конкретному процессу (rphost, rmngr, ragent), а затем редактируем имя процесса вручную, добавляя символ * в конец:

По умолчанию если процессов с одним и тем же именем несколько, то Performance monitor добавляет к каждому такому процессу порядковый номер (например, rphost#1). Для того, чтобы в имени счетчика отображался PID процесса необходимо отредактировать реестр, добавив в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance ключ ProcessNameFormat типа DWORD 32 бит со значением 2:

В файл настройки лога технологического журнала добавим следующие события:

Файл logcfg.xml будет выглядеть следующим образом:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log history="72" location="e:\logs">
        <property name="all"/>
        <event>
        	<eq property="name" value="CALL"/>
        </event>
        <event>
        	<eq property="name" value="SCALL"/>
        </event>
        <event>
        	<eq property="name" value="SDBL"/> 
        </event>
    </log>
</config>

Запускаем сбор логов, ждем падения рабочих процессов и проводим анализ собранных данных. Для начала взглянем на счетчики Performance monitor. Видим по ряду рабочих процессов rphost следующую ситуацию:

Количество потребляемой памяти либо неизменно, либо растет небольшими порциями, однако есть явные места, где происходит ступенчатый рост. Например, на графике выше потребление памяти процессом rphost с PID 29280 в период между 4 и 5 утра резко возросло с 4,7 до 9,7 Гб.

Взглянем на технологический журнал в такие промежутки времени и попробуем найти такие серверные вызовы CALL, свойство которых memory было бы максимальным. Данное свойство покажет нам объем занятой, но не освобожденной памяти за время серверного вызова.

Находим событие CALL следующего содержания:

21:40.004031-30955031,CALL,2,process=rphost,p:processName=rarus_master-copy,OSThread=8852,t:clientID=3404,t:applicationName=1CV8C,t:computerName=SRV-RARUS-11,t:connectID=2224,callWait=0,Usr=ИвановИИ,SessionID=1,Interface=bc15bd01-10bf-413c-a856-ddc907fcd123,IName=IVResourceRemoteConnection,Method=0,CallID=8986,MName=send,Memory=2571688604,MemoryPeak=2577368322,InBytes=111046682,OutBytes=111115207,CpuTime=24281250 

Серверный вызов, который согласно свойству memory занял, но не освободил более 2,5 Гб памяти. Причем свойство context у данного события отсутствует. Также обращаем внимание на свойство processName, которое в данном случае совпадает с именем базы, в которой зафиксирован данный вызов. Видим, что это не основная база, в которой работают пользователи, а ее копия.

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

К тому же, видим, что в некоторых случаях серверный вызов представляет собой выполнение регламентного задания, что и указано в свойстве func.

Найдем все processName, которые встречаются в логе:

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

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

1. Системное регламентное задание по обновлению индекса полнотекстового поиска.

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

Обращаем внимание на строку Mapped File, которая показывает, какой объем памяти от общего объема занят закешированными в памяти файлами. На закладке File Summary, можем посмотреть на список этих файлов:

Видим, что в топе по размеру файлы indexmain.bin и indextemp2.bin. Это и есть индекс полнотекстового поиска базы. Принимаем решение о полном отключении индекса, что освободит дополнительные ресурсы и уменьшит объем сеансовых данных. К тому же, из-за того, что предприятие активно работает практически 24/7, довольно сложно организовать регламентный пересчет индекса во внерабочие часы. Более подробную информацию об устройстве индекса полнотекстового поиска можно найти в конце статьи.

2. Серверные вызовы без контекста со значением свойства iname равным IVResourceRemoteConnection.

24:35.135009-24329972,CALL,1,process=rphost,p:processName=rarus,OSThread=11632,t:clientID=77,t:applicationName=1CV8C,t:computerName=PC1085,callWait=0,Usr=ИвановИИ,SessionID=2878,Interface=bc15bd01-10bf-413c-a856-ddc907fcd123,IName=IVResourceRemoteConnection,Method=0,CallID=13939,MName=send,Memory=2377792063,MemoryPeak=2382649864,InBytes=36796135,OutBytes=37680370,CpuTime=21406250 

Понять, что это за вызовы можно, если найти в логе технологического журнала событие CONN, которое фиксирует недавний старт соединения с тем же clientID:

24:10.524007-0,CONN,0,process=rphost,OSThread=11448,ClientID=77,Protected=1,Txt='Accepted, client=(2)хх.хх.хх.хх:53989, server=(2)хх.хх.хх.хх:1560, marker=1' 

Такие строки не являются утечкой памяти — это перенос клиентского соединения с одного рабочего процесса на другой. Сеансовые данные, которые были привязаны к старому клиентскому соединению переносятся на новое. Об этом и говорят нам вышеуказанные события.

3. Серверные вызовы CALL, фиксирующие выполнение длительных операций(запуск внешних отчетов).

00:29.195062-3641044,CALL,1,process=rphost,p:processName=rarus,OSThread=28448,t:clientID=3853,t:applicationName=1CV8C,t:computerName=PC-OMSK-203,t:connectID=1877,callWait=0,Usr=ИвановИИ,SessionID=1929,Context=Система.ПолучитьФорму : ВнешнийОтчет.РеестрБанковскойВыписки.Форма,Interface=bc15bd01-10bf-413c-a856-ddc907fcd123,IName=IVResourceRemoteConnection, … 

Ситуация с не освобождением памяти при этом возможна в двух случаях:

• Пользователь сформировал отчет за большой период времени и не закрыл форму отчета. Пока форма будет открыта внутри сеанса данные не будут очищены.
• Пользователь закрыл форму после формирования отчета, но внутри формы были циклические ссылки. Данная ситуация приводит к тому, что сеансовые данные по такой форме не освобождаются. Это может объяснить ступенчатую деградацию процессов rphost по используемой памяти.

Для проверки возможного наличия циклических ссылок добавим в файл настроек технологического журнала «1С» событие SCRIPTCIRCREFS.

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

После запуска сбора технологического журнала с новыми настройками видим в логах строки вида:

00:27.726064-1,SCRIPTCIRCREFS,2,process=rphost,p:processName=rarus,OSThread=28448,t:clientID=3853,t:applicationName=1CV8C,t:computerName=PC-OMSK-203,t:connectID=1877,SessionID=1929,Usr=ИвановИИ,AppID=1CV8C,ModuleName=ОбщийМодуль.ОтчетыСервер.Модуль,ProcedureName=ЗарегистрироватьПоле,Cycles='VariableName:
Информация
CircularRefsMembers:
Информация.НастройкиВарианта.Строки[0].Строки[0].Владелец, 
Информация.НастройкиВарианта.Строки[0].Строки[0].Владелец.Строки, 
Информация.НастройкиВарианта.Строки[0].Строки[0].Владелец.Строки[0], 
Информация.НастройкиВарианта.Строки[0].Строки[0].Владелец
VariableName:
НастройкаВарианта
CircularRefsMembers:
НастройкаВарианта.Владелец, 
НастройкаВарианта.Владелец.Строки, 
НастройкаВарианта.Владелец.Строки[0], 
НастройкаВарианта.Владелец
',Context='Система.ПолучитьФорму : ВнешнийОтчет.РеестрБанковскойВыписки.Форма 

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

Полнотекстовый поиск данных. Общее устройство и управление ППД в «1С»

Полнотекстовый поиск данных (англ.Full Text Searching, ППД) — это способ осуществления поиска в текстовых данных. В основном данный вид поиска используют для поиска в большом объеме данных, т. к. он существенно быстрее обычного поиска, который можно осуществить на языке запросов с помощью предиката ПОДОБНО (LIKE). Например, выполнение запроса с предикатом ПОДОБНО к нескольким миллионам строк неструктурированных текстовых данных может занять несколько минут, а полнотекстовый запрос всего несколько секунд или даже меньше, в зависимости от количества возвращаемых строк. Также предикат ПОДОБНО работает только с комбинациями символов в отличии от полнотекстовых запросов.

К основным задачам, решаемым с помощью механизма ППД можно отнести:

• Выполнение нечеткого поиска с возможностью указания порога нечеткости.
• Поиск с учетом синонимов различных языков. Например, русского, английского или украинского языка. В частности, поддержка английского языка помогает пользователям продуктов Adizes Executive Dashboard и 1C-Rarus: Finance management, которые предназначены для международного рынка.
• Поиск с учетом замещения. Когда части символов написаны на другой клавиатурной раскладке.
• Поиск с учетом транслитерации.
• Поиск слов или фраз, находящихся рядом с другими словами или фразами.
• Поиск с учетом поисковых операторов или регулярных выражений.

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

Механизм полнотекстового поиска используется в различных системах. В том числе, в системах управления базами данных и поисковых системах. Платформа 1С:Предприятие 8, также включает в себя данный механизм. Однако, из-за недостатка открытых источников с описанием его архитектуры, предлагаем ознакомиться с аналогичным механизмом продукта Microsoft SQL Server.

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

• Пользовательские таблицы. Непосредственно таблицы информационной базы, по которым осуществляется полнотекстовое индексирование.
• Средство сбора полнотекстовых данных. Отвечает за планирование заполнения полнотекстовых индексов и управление им.
• Файлы тезауруса. Файлы содержащие синонимы искомых слов.
• Список стоп-слов. Список наиболее встречающихся слов, которые исключаются при поиске.
• Обработчик запросов. Отвечает за компиляцию и выполнение SQL-запросов. Если SQL-запрос включает запрос полнотекстового поиска, то запрос направляется в средство полнотекстового поиска.
• Средство полнотекстового поиска. Отвечает за компиляцию и выполнение полнотекстовых запросов, поддержку индексов, а также взаимодействует с файлами тезауруса и списков стоп-слов.
• Модуль записи индекса. Формирует структуру, используемую для хранения индексов.
• Диспетчер управляющей программы фильтрации. Отвечает за мониторинг состояния узла управляющей программы фильтрации (fdhost.exe) для полнотекстового поиска.
• Обработчик протокола. Отвечает за передачу данных из памяти в узел управляющей программы фильтрации, в котором требуемым образом применяется фильтрация и средство разбиения по словам.
• Фильтры. Отвечает за предварительную фильтрацию текстовых данных при полнотекстовой индексации. Например, при обработке XML структуры файла удаляется форматирование текста.
• Средства разбиения по словам и парадигматические модули. Используется для лингвистического анализа текстовых данных при полнотекстовой индексации. Например, компонента находит границы слов в соответствии с лексическими правилами данного языка (разбиение по словам).

Схема механизма полнотекстового поиска данных Microsoft SQL Server

Стоит отметить, что основной компонентой механизма ППД является «Средство полнотекстового поиска», т. к. она отвечает за поддержку индексирования и формирование запросов.

Архитектура полнотекстового индекса

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

Представим, что в информационной базе существует таблица «Номенклатура», у которой включен полнотекстовой индекс. Пример содержимого таблицы:

После выполнения построения индексов система подготовит следующий фрагмент индекса:

Описание колонок:

• Ключевое слово — содержит представление лексемы, извлеченной при индексировании.
• Идентификатор колонки — соответствует идентификатору индексируемой колонки. При этом нумерация колонок начинается с 0.
• Идентификатор записи — соответствует значению полнотекстового ключа конкретной таблицы.
• Позиция — содержит целочисленное значение, которое отвечает за относительное смещение в хранимом значении. Например, во второй записи лексема «Наполеон» является второй лексемой из чего система определяет позицию равной 2. При этом позиция лексемы учитывает стоп-слова. 

Также стоит обратить внимание, что лексемы «со» или «с» были удалены из полнотекстового индекса. Это связано с тем, что они являются стоп-словами. Удаление стоп-слов из полнотекстового индекса может привести к значительной экономии дискового пространства, тем самым увеличивая производительность запросов.

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

Процесс полнотекстового индексирования

Для выполнения операции полнотекстового индексирования средство полнотекстового поиска перемещает пакеты данных в память. Затем управляющая программа получает данные пакеты и выполняет фильтрацию с разбиением по словам, а также преобразовывает входные данные в инвертированный список слов. После чего средство полнотекстового поиска запрашивает конвертированные данные из списка слов, удаляет стоп-слова и сохраняет списки слов в виде пакета в один или несколько инвертированных фрагментов.

При этом для удаления стоп-слов и нормализации ключевых слов перед их сохранением в полнотекстовом индексе или фрагменте индекса может быть проведена дополнительная обработка.

После завершения операции заполнения инициируется заключительный процесс слияния фрагментов индекса в один основной полнотекстовый индекс.

Обработка полнотекстовых запросов

Обработчик запросов инициализирует запрос к средству полнотекстового поиска. Средство полнотекстового поиска разбивает запрос по словам при необходимости дополняет синонимами, далее выполняется морфологический поиск и обработка стоп-слов. Затем полнотекстовые части запроса преобразуются в формат операторов SQL. Во время выполнения запроса происходит обращение к инвертированному индексу. Результат запроса возвращаются клиенту.

Устройство и управление в платформе «1С:Предприятие 8»

Платформа «1С:Предприятие 8» использует собственно разработанный механизм полнотекстового поиска, что позволяет отказаться от поддержки полнотекстового поиска самих систем управления базами данных. Однако его архитектура не отличается от ранее рассмотренной архитектуры Microsoft SQL Server. Например, Механизм ППД платформы «1С:Предприятие 8» аналогично разделяется на: файлы полнотекстового индекса и механизма полнотекстового поиска. При этом сам полнотекстовый индекс разделяется на основной и дополнительный индекс, которые соответствуют основному и дополнительным фрагментам.

Место хранения

Платформа «1С:Предприятие 8» размещает все файлы полнотекстового поиска данных в служебном каталоге 1Cv8FTxt:

• Для файловой базы: ..\<Каталог базы>\1Cv8FTxt\
• Для клиент-серверной базы: ..\srvinfo<порт сервера>\reg_<порт сервера>\<Идентификатор базы>\1Cv8FTxt\

В данном каталоге размещаются все файлы необходимые для механизма ППД. Например, файлы основного (indexMain.bin) и дополнительного индекса (indexPartial.bin), временные файлы изменений (changesХХХХХХХХХХХХХХ.log) и многие другие.

Инструменты управления

Управление полнотекстовым поиском осуществляется как в режиме 1С:Предприятие, так и с помощью методов встроенного языка.

Для открытия окна управления в режиме 1С:Предприятия необходимо выполнить действия:

• Обычное приложение:
  • Пункт меню «Операции».
  • Управление полнотекстовым поиском.
• Управляемое приложение:
  • Пункт меню «Главное меню».
  • Функции для технического специалиста / Все функции.
  • Стандартные.
  • Управление полнотекстовым поиском.

Окно «Управление полнотекстовым поиском» в обычном режиме

Окно «Управление полнотекстовым поиском» в управляемом режиме

К основным операциям можно отнести:

• Обновление индекса без слияния — Создание или обновление дополнительных индексов.
• Обновление индекса со слиянием — Создание или обновление основных индексов.
• Очищение индекса — Обнуление существующего основного индекса.
• Проверка индекса — Анализ актуальности текущего состояния индексов.

Во встроенном языке существуют методы, соответствующие данным операциям:

• Обновление индекса без слияния
  ПолнотекстовыйПоиск.ОбновитьИндекс(Ложь)
• Обновление индекса со слиянием
  ПолнотекстовыйПоиск.ОбновитьИндекс(Истина)
• Очищение индекса
  ПолнотекстовыйПоиск.ОчиститьИндекс()
• Проверка индекса
  ПолнотекстовыйПоиск.ИндексАктуален()

Также важно понимать, что полнотекстовый поиск будет осуществляться по объектам, у которых установлено свойство Полнотекстовый поиск/Использовать. Данное свойство установлено по умолчанию и если перед нами встает задача редуцировать количество объектов, участвующих в поиске, то для конфигураций, стоящих на поддержке от типовых приходится включать возможность редактирования, что приводит к более сложному процессу обновления. В типовых решениях существуют объекты, состоящие из огромного количества реквизитов, тип которых попадает в спектр поиска: Строка, Данные ссылочного типа (ссылки на документы, справочники),Число, Дата, ХранилищеЗначения.

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

Использование полнотекстового поиска данных должно быть осознанным

Итак, какие выводы можно сделать из данного случая и чему научила нас эта история.

Еще и еще раз убедились, что “Everybody lies” (Все врут) как говорил Доктор Хаус из культового сериала про врачебную экспертизу. В нашем случае заказчик уверяет, что проблем по потреблению памяти не наблюдается, а они есть. И разумеется эксперт должен полагаться только и исключительно на факты, а не на слова. Поэтому всегда проверяем и перепроверяем гипотезы. В обязательном порядке при обнаружении проблем, связанных с утечкой памяти в кластере «1С» нужно убедиться, что правильно произведены настройки по перезапуску рабочих процессов. Подробнее о перезапуске рабочих процессов можно прочитать в статье Замедление работы 1С:Управление торговлей через 6 часов после запуска сервера «1С».

Второе, что следует сказать, расследование  может быть многоэтапным и к этому нужно быть готовым. Проверили базовую гипотезу по памяти, отвергли или приняли ее, исключили «шум» в виде ненужных баз в продуктивном контуре и далее сфокусировались на поиске конкретного виновника по утечке памяти.

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

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

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

Поэтому в данном случае можно было бы рекомендовать:

• Оставлять ППД только и исключительно на рабочей базе.
• Позаботиться о том, чтобы объем оперативной памяти был бы достаточен в момент слияния таблиц индексов поиска.
• Включать обновление только и исключительно в момент технологического перерыва и, возможно, даже не ежедневно.
• Произвести отключение полнотекстового поиска для объектов метаданных, оставив только нужные или даже спуститься ниже — к реквизитам объектов.
• И как крайний вариант — рассмотреть вопрос об отказе использования механизма ППД.

Клиентом были выбраны пункты «оставить ППД только и исключительно на рабочей базе» и «отказ от использования механизма ППД». Проблем с падением более не наблюдалось.

Интересующиеся базами данных и 1С:Предприятием могут посмотреть предыдущие статьи от экспертов «1С‑Рарус»:

• Страничные блокировки в MS SQL Server при проведении документа в документе в «1С»
• База «1С» растёт и всё тормозит. Что делать?