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

Индекс ППД в 1С 8.3 — это индекс полнотекстового поиска данных: отдельный набор файлов, по которому платформа ищет слова сразу во всех справочниках и документах. Ошибку или тормоза почти всегда лечат одинаково: перенести обновление индекса на ночь, а повреждённый индекс очистить и построить заново — Администрирование → Общие настройки → Полнотекстовый поиск в БП 3.0 и других конфигурациях на БСП.

Типичная картина: днём база «подвисает» на пару минут, в консоли кластера висит фоновое задание «Обновление индекса ППД», а поиск по всем данным выдаёт ошибку или пустой результат. Разберём, откуда берётся проблема, как доказать, что виноват именно индекс, и как убрать её без потери данных.

Как устроен индекс ППД в платформе 1С

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

📁 Где лежат файлы:

• файловая база — папка 1Cv8FTxt внутри каталога информационной базы (рядом с 1Cv8.1CD);
• клиент-серверная база — каталог кластера, по умолчанию C:\Program Files\1cv8\srvinfo\reg_1541\<идентификатор базы>\1Cv8FTxt.

🔄 Как индекс обновляется:

1. Пользователь записывает документ или элемент справочника.
2. Платформа запоминает, что объект изменился и его надо переиндексировать.
3. Регламентное задание «Обновление индекса ППД» забирает накопившиеся изменения и дописывает их в дополнительный индекс.
4. Задание «Слияние индекса ППД» объединяет дополнительный индекс с основным. Это самая тяжёлая операция: она перечитывает большие файлы и нагружает диск и процессор.

Что попадает в индекс, задаёт разработчик: у объектов метаданных и их реквизитов в конфигураторе есть свойство «Полнотекстовый поиск» со значениями «Использовать» и «Не использовать». В типовых конфигурациях индексируется много, поэтому на базе в десятки гигабайт индекс легко разрастается до нескольких гигабайт.

Как понять, что базу тормозит именно индекс ППД

Прежде чем что-то чистить, убедитесь, что виноват действительно полнотекстовый поиск. Признаки:

• ⏱ замедление приходит волнами, с регулярным интервалом — совпадает с расписанием регламентного задания;
• 🖥 в диспетчере задач сервера растёт нагрузка процесса rphost.exe, а на диске — активность в папке 1Cv8FTxt;
• 🔍 поиск по всем данным выдаёт ошибку, работает очень долго или не находит свежие документы;
• 📈 сразу после массовой загрузки (перенос данных, обработка на тысячи документов) база заметно тормозит несколько часов.

Проверка через регламентные задания

В конфигурациях на БСП откройте Администрирование → Обслуживание → Регламентные операции → Регламентные и фоновые задания. Найдите в списке «Обновление индекса ППД» и «Слияние индекса ППД» и посмотрите:

• расписание (как часто запускается);
• время последнего запуска и длительность;
• состояние: «Завершено», «Выполняется» или «Завершено аварийно».

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

Проверка в форме полнотекстового поиска

В форме Администрирование → Общие настройки → Полнотекстовый поиск (ссылка «Настройка полнотекстового поиска») видно, актуален ли индекс и на какую дату. Если дата актуальности отстаёт на дни, а изменения в базе идут, значит обновление не доходит до конца.

Без БСП ту же форму открывают через Все функции → Стандартные → Управление полнотекстовым поиском. Пункт «Все функции» включается в параметрах программы.

Когда индекс ни при чём

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

Как исправить ошибку индекса ППД: от мягкого к радикальному

Идите по способам по порядку. Каждый следующий тяжелее предыдущего.

Способ 1. Перенести обновление и слияние на нерабочее время

Если ошибки нет, а есть только тормоза, этого часто хватает.

1. Откройте список регламентных заданий (путь выше).
2. Откройте «Слияние индекса ППД» и задайте расписание: раз в сутки, ночью.
3. Для «Обновление индекса ППД» увеличьте интервал, чтобы оно не запускалось каждые несколько минут в разгар рабочего дня.
4. Сохраните и проверьте на следующий день, ушли ли «волны».

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

Способ 2. Обновить индекс вручную

1. Откройте настройку полнотекстового поиска.
2. Нажмите «Обновить индекс».
3. Дождитесь окончания. На большой базе это может занять от десятков минут до нескольких часов.

Если ручное обновление проходит без ошибки, сбой был разовым (например, файл был занят антивирусом).

Способ 3. Очистить индекс и построить заново

Это основное лечение повреждённого индекса.

1. Предупредите пользователей: пока индекс строится, поиск по всем данным работать не будет, а сервер будет нагружен.
2. В форме настройки нажмите «Очистить индекс ».
3. Затем нажмите «Обновить индекс» и дождитесь окончания. Лучше запускать вечером или в выходной.

Способ 4. Удалить папку индекса вручную

Нужен, когда кнопка «Очистить индекс» сама падает с ошибкой.

1. Сделайте резервную копию базы (выгрузку .dt или копию средствами СУБД).
2. Завершите работу пользователей и остановите службу (для сервера).
3. Переименуйте папку 1Cv8FTxt, например в 1Cv8FTxt_old — не удаляйте сразу.
4. Запустите службу, зайдите в базу и выполните «Обновить индекс».
5. Когда поиск заработает, старую папку можно удалить.

Способ 5. Сузить состав индекса или отключить поиск

Если индекс огромный, а полнотекстовым поиском никто не пользуется, его можно запретить кнопкой «Отключить» в той же форме. Индексирование прекратится, нагрузка уйдёт.

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

Технологический журнал: как поймать причину сбоя

Если ошибка повторяется после пересборки, нужна точная причина. Её даёт технологический журнал. Его настраивают файлом logcfg.xml в каталоге C:\Program Files\1cv8\conf\ на сервере (для файловой базы — на компьютере, где выполняются задания).

Минимальная настройка: исключения и события обновления полнотекстового индекса.

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1C_TechLog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="FTEXTUpd"/>
    </event>
    <property name="all"/>
  </log>
</config>

Как работать с журналом:

1. Создайте папку D:\1C_TechLog и выдайте права на запись пользователю, от имени которого работает служба 1С.
2. Положите logcfg.xml в каталог conf. Платформа подхватывает файл без перезапуска, обычно в течение минуты.
3. Дождитесь очередного запуска задания или запустите обновление индекса вручную.
4. Откройте свежие файлы .log и ищите строки EXCP рядом по времени с FTEXTUpd. В свойствах события будет текст исключения: нехватка места, отказ в доступе, занятый файл.
5. Сразу после диагностики уберите logcfg.xml или переименуйте его.

Что посмотреть на стороне СУБД

Сам индекс ППД в SQL не хранится, но задание его обновления читает изменённые объекты из базы. Если задание висит, проверьте в MS SQL, не ждёт ли его сеанс блокировку:

SELECT r.session_id, r.status, r.wait_type, r.wait_time,
       r.blocking_session_id, r.cpu_time, r.logical_reads
FROM sys.dm_exec_requests r
WHERE r.database_id = DB_ID('ИмяБазы');

Ненулевой blocking_session_id говорит, что запрос ждёт чужую транзакцию. Длинные wait_time с типами ожидания ввода-вывода указывают на медленный диск. В PostgreSQL ту же картину даёт представление pg_stat_activity (поля state, wait_event_type, wait_event).

Причины и решения в одной таблице

Профилактика: чтобы индекс ППД больше не мешал работе

• 🌙 Слияние — только ночью. Это самый дешёвый и действенный шаг.
• 🛡 Исключение в антивирусе для папок 1Cv8FTxt и всего каталога srvinfo. Антивирус, проверяющий каждый файл индекса при записи, — частая причина блокировок.
• 💾 Запас места на диске. Держите свободным объём не меньше текущего размера папки индекса: при слиянии нужны временные файлы.
• 📦 Массовые операции — с планом. Перед загрузкой тысяч документов можно временно отключить задание обновления, а после загрузки обновить индекс вручную ночью.
• 🔁 Проверка после переноса базы. Перенесли базу на другой сервер или восстановили из .dt — сразу очистите и постройте индекс: старые файлы к новой базе не подходят.
• 👀 Контроль заданий. Раз в неделю смотрите состояние «Обновление индекса ППД» в списке регламентных заданий. Аварийное завершение, которое никто не заметил, накапливает очередь.

Если есть разработчик, индекс можно обновлять порциями из своего регламентного задания. Встроенный язык даёт для этого метод ПолнотекстовыйПоиск.ОбновитьИндекс():

// Обновить индекс без слияния, только очередную порцию изменений
Если ПолнотекстовыйПоиск.ПолучитьРежимПолнотекстовогоПоиска() = РежимПолнотекстовогоПоиска.Разрешить Тогда
    ПолнотекстовыйПоиск.ОбновитьИндекс(Ложь, Истина);
КонецЕсли;

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

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