---
name: omniroute_db_fts_bloat
description: "OmniRoute: storage.sqlite раздувается через FTS5-индекс memory_fts (15 ГБ на 308 записей) и журнал -wal (17 ГБ); симптом — старт шины 4 минуты на 89% CPU. Лечится rebuild+VACUUM; поставлены сторож и недельный optimize."
metadata: 
  node_type: memory
  type: project
  originSessionId: abc7cc05-ae71-45e4-9d26-a815940af85c
  modified: 2026-08-21T18:29:27.092Z
---

**Инцидент 21.08.2026.** На mini оставалось 39 ГБ из 228. Обжора — БД шины
[[omniroute_cloud_bus]]: `storage.sqlite` 18 ГБ + `storage.sqlite-wal` 17 ГБ.
По `dbstat` 15.4 ГБ из 18 занимали теневые таблицы FTS5 `memory_fts_data`
(12.5 ГБ) и `memory_fts_docsize` (2.9 ГБ) — **при 308 записях в `memories`**.
Индекс копил сегменты от удалённых записей, `optimize` не вызывался никогда.

**Главный симптом, который легко списать не на то:** шина поднимается
**4 минуты** на 89% CPU, порт слушает, но HTTP не отвечает (curl → 000).
В Changelog 2026-08-05 это уже принимали за «холодный старт на 10-гигабайтной
БД» и один раз даже зря откатили базу на снапшот. После чистки старт — **12 секунд**.

**Лечение (простой ~10 минут, вернуло 32 ГБ):**
1. `sudo launchctl bootout system/com.cebers.omniroute` — **сама остановка**
   сливает журнал в базу и удаляет `-wal` (+17 ГБ сразу).
2. `sudo -u omniroute_svc sqlite3 <db> "INSERT INTO memory_fts(memory_fts) VALUES('rebuild');"`
   — 26 с, FTS 15.4 ГБ → 0. Операция безопасна: индекс полностью производный
   от таблицы `memories` (`content='memories'`), данные не трогает.
3. `PRAGMA integrity_check` → `ok`, затем `VACUUM` — 15 с, файл 18 ГБ → 2.5 ГБ.
4. Поднять шину, дождаться `health=200`, проверить живым вызовом.

**How to apply:** sqlite вызывать ТОЛЬКО через `sudo -u omniroute_svc` — от root
файлы `-wal`/`-shm` сменят владельца и шина потеряет право записи. Перед правками
снимать дамп `provider_connections` / `provider_nodes` / `api_keys` / `key_value`
и сверять счётчики после (в июле апгрейд уже молча сносил codex-подключения).

**Что поставлено, чтобы не повторилось:** LaunchAgent
`com.cebers.mini-disk-watch` (каждые 15 мин, пороги: диск < 25 ГБ, БД > 4 ГБ,
`-wal` > 2 ГБ) пишет health-файл для тайла «Диск mini + БД шины»; LaunchDaemon
`com.cebers.omniroute-db-maintenance` (воскресенье 04:30) делает
`wal_checkpoint(TRUNCATE)` + FTS `optimize` без остановки шины. У самой шины
до этого **не было карточки в ops_dashboard** — поэтому инцидент и не всплыл;
теперь есть (`omniroute`, http-проверка на `:20129/api/monitoring/health`).

**Мимо цели:** `PRAGMA journal_size_limit` не спасает — это настройка
соединения, а не файла (выставил 512 МБ, новое подключение показывает 32768).
`SQLITE_MAX_SIZE_MB=1024` в `.env` шины на раздувание тоже никак не влияет —
база спокойно росла до 18 ГБ.
