av
d33f37249c
- роадмап отвечает «что умеет и чего не умеет»: PLAN.md → ROADMAP.md, четыре канонические секции, достигнутые звенья строками в «Готово», цели переформулированы возможностями приложения - задачи: род работы и «Затрагивает» набору спринта, 34 заголовка в форму действия, «Завершение» целей перечнями со ссылкой из каждой задачи - вычитка проходами task-form и doc-wording, починены протухшие факты в README, паспорте и review.md
2.4 KiB
Не держать весь журнал в памяти при пересборке
- Секция: Ядро
- Зачем: Учёт доставок и список путей архива материализуются целиком: расход растёт вместе с журналом, а у журнала конца нет
- Теги: goal:journal-and-rebuild
healthlog reindex материализует целиком две вещи: учёт доставок из базы и
список путей архива. На сегодняшнем объёме (сотня тел) это незаметно, на
квартальном (~12 тысяч) — терпимо, а дальше растёт линейно и без предела:
журнал по определению не подчищается до следующего проверенного экспорта.
Отдельно к этому примешивается размер заголовков: MaxHeaderBytes у
сервера не задан, то есть верхней границы у колонки delivery.headers нет
вовсе. Раздутый заголовок множится на число доставок.
Порог, за которым это перестаёт быть теорией, не измерен — с него и стоит начинать, если задача берётся. Лечится потоковым перечислением журнала (курсор по учёту, обход каталога партиями по суткам) вместо двух срезов в памяти.
Сегодня недостижимо, поэтому приоритет низкий. Естественно склеивается с ретеншеном сырого архива: та задача задаёт, где у журнала конец, эта — как его читать, не поднимая целиком.
Готово, когда пересборка на журнале в десятки тысяч доставок идёт с потреблением памяти, не зависящим от его длины.
Связано: internal/replay, cmd/healthlog/reindex.go.
Двигает строку «Завершения» цели: «Расход пересборки не растёт вместе с журналом».