> For the complete documentation index, see [llms.txt](https://docs.onerpa.ru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.onerpa.ru/mcp-servery-1c/servery/code-metadata-search/vremya-indeksacii.md). # Время первичной индексации Первичная индексация большой конфигурации 1С — отдельная ресурсоёмкая операция. Она может занимать много часов; рассчитывать на завершение за одну ночь без замера на своей выгрузке не стоит. Быстрый запуск контейнера и доступность файлового поиска не означают, что векторный поиск, формы и структурные индексы уже готовы. ## Что известно о времени для УТ и ERP **Подтверждённых сопоставимых замеров полного первого запуска типовых УТ и ERP для CPU, локальной GPU и облачного API пока нет.** Универсальную таблицу часов по одному числу объектов нельзя считать измерением или гарантией. Для конкретной выгрузки нужны её версия, объём кода, число чанков и настройки модели. | Режим эмбеддингов | Ориентир для планирования | Что проверить до большого запуска | | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | Локальная модель на CPU | Многочасовое окно; точное число часов — по пробному прогону. Подтверждённой нормы для УТ/ERP нет | Модель и её размер, реально доступные CPU и RAM контейнера, отсутствие swap, локальный SSD | | Локальная модель на GPU | Ускоряется вычисление эмбеддингов, но не обязательно весь запуск. Подтверждённого коэффициента ускорения для УТ/ERP нет | Модель действительно помещается в VRAM и использует GPU; загрузка на CPU и сброс слоёв в RAM меняют результат | | Внешний API, например OpenRouter | Срок зависит от пропускной способности и лимитов провайдера; API не гарантирует завершение за ночь. Подтверждённой нормы для УТ/ERP нет | Модель и размерность, токены/мин, запросы/мин, задержка, `429`, повторы, бюджет и стабильность соединения | `light`/`light-beta` описывает состав образа, а не скорость эмбеддингов. Сервер с `light` может обращаться и к облаку, и к LM Studio на локальном компьютере. GPU в LM Studio и GPU внутри контейнера — разные способы исполнения; наличие видеокарты само по себе не подтверждает ни один из них. Ранее приводившиеся диапазоны «2–6 / 10–20 / 20–60 часов на CPU» и «30–60 минут / 2–4 / 5–10 часов на GPU» не привязаны к воспроизводимым замерам. Использовать их как норму для своей УТ или ERP не следует. ## Подтверждённый пример: ЗУП через OpenRouter В отдельном прогоне 05.09.2026 первичное заполнение пустых индексов ЗУП завершилось за **3 ч 52 мин 10 с** — по итоговому сообщению `INDEXING COMPLETE`. Это наблюдение одного корпуса, **не норматив для УТ/ERP и не сравнение CPU с GPU**. | Параметр | Зафиксировано в журнале | | ------------------- | -------------------------------------------------------------------------------------------------- | | Начальное состояние | Коллекции metadata, code, help и forms пусты | | Источники | 12 106 файлов BSL, 11 215 единиц метаданных XML, 1 782 файла HTML справки | | Эмбеддинги | OpenRouter, `qwen/qwen3-embedding-8b`, 4 096 измерений; локальная модель не использовалась | | Параллелизм | 8 workers разбора, 6 embedding workers, размер батча 64 | | Векторное хранилище | zvec, профиль `fast_index`, HNSW, fp16, mmap | | Охват | Метаданные, код, справка, структура, граф зависимостей, формы, XSD; финальная оптимизация включена | | Результат | `INDEXING COMPLETE`, `total time: 3h 52m 10s` | В итоговой строке стоит `mode=incremental`: это выбранный алгоритм, а не доказательство повторного запуска. В этом случае начальные коллекции были пусты, а исходники классифицированы как `new`. Версия другой конфигурации, характеристики оборудования и лимиты API могут существенно изменить время; полного сопоставимого протокола для УТ/ERP на CPU, GPU и API этот пример не заменяет. ## Подтверждённый пример: только структурный разбор ЗУП В отдельном прогоне 07.09.2026 разбор и запись структурного индекса той же выгрузки ЗУП (12 106 файлов BSL) заняли **6 мин 20 с**: 232 931 символ, 1 728 817 вызовов, предупреждений `Overlapping definition` не было, INFO `N/M file(s) done` шла каждые 60 секунд. Это не полный первый запуск и не время векторных эмбеддингов: замерена дорожка, которая раньше могла два часа не печатать ни строки. Восьмикратная разница полного sub-index (часы против \~17 минут на stable) этим разбором не объясняется — сам парсер на этом корпусе укладывается в минуты. ## Из чего складывается время * Чтение и хеширование исходников, определение формата и извлечение метаданных. * Разбор BSL, HTML и форм, разбиение текста на чанки. * Вычисление эмбеддингов — локально или через API. * Запись, полнотекстовая индексация и оптимизация векторного хранилища. * Структурный индекс, граф зависимостей, формы и XSD — согласно включённым дорожкам. * Проверка целостности и публикация готового поколения. Этапы могут перекрываться. Время ответа embedding API нельзя просто умножить на число файлов: файлы имеют разный размер, один файл даёт несколько чанков, запросы идут батчами и параллельно. Замер качества поиска на небольшом корпусе также не измеряет полный первый запуск УТ/ERP. ## Как оценить оставшееся время на своей выгрузке 1. Сохраните исходную выгрузку неизменной на время прогона. Закрепите модель, размерность, формат исходников и набор дорожек. Не меняйте одновременно модель, размер батча и параллелизм. 2. Смотрите журнал своего контейнера: ```sh docker logs --timestamps --follow 1c_code_metadata_mcp ``` Если имя другое, подставьте его. Перед передачей журнала в поддержку удалите ключи, персональные данные и закрытые пути. 3. Найдите строки **своей** дорожки, а не чужой. Векторные дорожки пишут `code progress`, `metadata progress` или `help progress`: обработанные/всего файлы, число чанков, `files/min`, `ETA` и размер очереди. Структурный проход этих строк не пишет — у него `Sub-index pass: started` и затем INFO `N/M file(s) done` примерно раз в минуту, даже когда ни один файл не залип. Warning `still active past` относится к конкретной единице, а не ко всему проходу. Начальный прогрев модели не показателен; сравните несколько последовательных интервалов на крупных и небольших файлах. Если INFO структурного прохода нет дольше минуты, монитор выключен (`SUB_INDEX_PROGRESS_WARN_SEC=0`) либо образ старше этой правки. 4. Используйте `ETA` **только как оценку остатка текущей дорожки**, а не всего сервера. Для ручной оценки по двум отметкам: ``` скорость = (обработано_2 - обработано_1) / (время_2 - время_1) остаток_дорожки = (всего - обработано_2) / скорость ``` Единицы времени должны совпадать. При нулевом приросте оценка не определена; это повод проверить очередь, провайдера, CPU, диск и ошибки, а не обещать время завершения. Не объединяйте отметки разных запусков или дорожек. 5. К остатку добавьте ещё не выполненные дорожки и финальную оптимизацию. Если их ещё не измеряли, итоговая оценка остаётся неполной. Для окна обслуживания учитывайте самый медленный из наблюдавшихся интервалов, а не только лучший. 6. После завершения сохраните `Lane '…' completed in …`, итоговую строку `INDEXING COMPLETE` / `total time` и результат `stats`. Живой контейнер, `healthy` или выполненная на 100% дорожка сами по себе не доказывают готовность всех индексов. ## Как получить сопоставимый замер первичной индексации Замер проводится на **отдельном новом каталоге данных**, с той же выгрузкой и тем же набором дорожек. Рабочий индекс удалять нельзя. Первый запуск не должен переиспользовать готовое поколение или ранее вычисленные эмбеддинги. Само слово `incremental` в итоговом логе не доказывает наличие старого индекса: этот режим может начать работу и на пустом каталоге. Для каждого замера фиксируют: * УТ или ERP, точную версию, формат Designer XML/EDT и состав расширений; * число BSL/XML/HTML-файлов, объём исходников и итоговое число чанков по дорожкам; * тег и digest образа; доступные контейнеру CPU/RAM, диск и способ монтирования; * CPU/GPU и VRAM либо провайдера API; точную модель, размерность и префиксы; * включённые дорожки, `PARSE_WORKERS`, `EMBEDDING_CONCURRENCY`, `EMBED_BATCH_SIZE_API` или `EMBED_BATCH_SIZE_LOCAL`; * отдельное время загрузки/прогрева модели, длительность каждой дорожки, оптимизации и всего запуска; * для API — фактические токены, стоимость, лимиты, число ошибок и повторов; * успешное завершение и готовность поколения; незавершённый или зависший прогон не становится замером времени успешной индексации. Первый холодный запуск, повторный запуск на пустой БД с прогретой моделью и инкрементальное обновление публикуются отдельно. До появления таких результатов конкретные часы для типовых УТ/ERP остаются непроверенными. ## Перезапуск и сохранность прогресса * Постоянный том `/app/chroma_db` сохраняет данные при **пересоздании** контейнера. Обычный `docker restart` того же контейнера сам по себе не удаляет его файловый слой, но без тома удаление контейнера удалит и данные из этого слоя. * Наличие тома не означает сохранение каждого рассчитанного чанка: это зависит от механизма восстановления в установленной версии. В реализации с чекпоинтами только завершённых дорожек незавершённая дорожка строится заново даже при правильном `-v`. * При неизменных исходниках и настройках готовое корректное поколение не требует полного переиндексирования. Изменение модели, несовместимость формата, повреждение хранилища или осознанный сброс могут потребовать перестройки. * Если `stats().indexing.last_outcome` стал `degraded`, а у коллекции `write_health=failed` и `rebuild_required=true`, инкрементальный тик больше не клонирует пустые поколения и не удаляет каталог `.rebuild`. Поиск по опубликованному поколению продолжает отвечать. Лечение — `reindex(force=true)`: пересобираются только повреждённые дорожки, здоровые (в том числе миллионы чанков `code`) переносятся. Если повреждённых дорожек нет, `force=true` по-прежнему начинает пустое поколение. * После полной пересборки граф зависимостей пишет XML в одну транзакцию (`SUB_INDEX_BULK_LOAD=true`). Если дорожка `dependency_graph` после `force` ползёт десятками файлов в час, это признак образа без этой правки либо выключенного bulk-load. * Не используйте `RESET_DATABASE=true`, удаление тома или `docker compose down -v` как обычный способ восстановления после прерывания. Сначала сохраните журнал и выясните причину. * Для плановой остановки дайте процессу время завершиться, например `docker stop --time 120 1c_code_metadata_mcp`. Это время ожидания, не гарантия завершения всей индексации; по истечении таймаута Docker может остановить процесс принудительно. * Сбой питания может повредить векторное хранилище. Том, чекпоинт и журнал рассчитанных эмбеддингов не заменяют исправный диск и резервную копию; повреждённый индекс нельзя объявлять готовым по счётчику прогресса. * Даже при побатчном сохранении нельзя гарантировать нулевую повторную оплату каждого API-запроса: провайдер мог уже принять запрос, а процесс — не успеть получить ответ или зафиксировать его на диске. Повториться могут незавершённые запросы; при нескольких workers их может быть несколько. Настройки модели и параллелизма: [конфигурация](/mcp-servery-1c/servery/code-metadata-search/konfiguraciya.md). Команды запуска и монтирование: [установка](/mcp-servery-1c/servery/code-metadata-search/ustanovka.md).