Files
healthlog/docs/tasks/items/rebuild-memory-footprint.md
av 3d24248075 docs: документация приведена к канону av-dev-pm 4
- каждая запись каталога задач получила тип вместо тега kind: и префикса
  заголовка; секция роадмапа «Разработка» стала «Сопровождением», порядок
  секций канонический
- поправлены протухшие факты: нереализованные маршруты Read API, MCP и
  `healthlog import`, словарь слоёв в инварианте, семантика гейта по покрытию
  диффа, периметр перестал дублировать security.md
- замер слияния переведён с находки 49 на находку 54, заполнены Purpose спек
  storage и parsing
2026-08-05 19:09:35 +03:00

2.4 KiB

🧹 Не держать весь журнал в памяти при пересборке

  • Тип: chore
  • Категория: Ядро
  • Зачем: Учёт доставок и список путей архива материализуются целиком: расход растёт вместе с журналом, а у журнала конца нет
  • Теги: goal:journal-and-rebuild

healthlog reindex материализует целиком две вещи: учёт доставок из базы и список путей архива. На сегодняшнем объёме (сотня тел) это незаметно, на квартальном (~12 тысяч) — терпимо, а дальше растёт линейно и без предела: журнал по определению не подчищается до следующего проверенного экспорта.

Отдельно к этому примешивается размер заголовков: MaxHeaderBytes у сервера не задан, то есть верхней границы у колонки delivery.headers нет вовсе. Раздутый заголовок множится на число доставок.

Порог, за которым это перестаёт быть теорией, не измерен — с него и стоит начинать, если задача берётся. Лечится потоковым перечислением журнала (курсор по учёту, обход каталога партиями по суткам) вместо двух срезов в памяти.

Сегодня недостижимо, поэтому приоритет низкий. Естественно склеивается с ретеншеном сырого архива: та задача задаёт, где у журнала конец, эта — как его читать, не поднимая целиком.

Готово, когда пересборка на журнале в десятки тысяч доставок идёт с потреблением памяти, не зависящим от его длины.

Связано: internal/replay, cmd/healthlog/reindex.go.

Двигает строку «Завершения» цели: «Расход пересборки не растёт вместе с журналом».