Форум

После того, как я почистил вручную таблицы b_cache_tag и b_event_log (TRUNCATE TABLE) они перестали стремительно расти. Сейчас b_cache_tag весит 38 мб, набралось за 2 месяца работы сайта, не знаю плохо это или нет, но всё работает стабильно.
Я не делал никаких дополнительных действий, управляемый кеш компонентов включен. Причины проблемы так и не знаю, возможно исправили разрастание таблицы в обновлении, а может пропал не качественный кусок кода в моих скриптах.

Прошло почти 2 года, как разрешился данный вопрос?

Я сегодня заметил нерациональное разрастание b_cache_tag. В собственном компоненте после $this->StartResultCache делаю:
$CACHE_MANAGER->RegisterTag("my_component_".$arObject['Id'])

В итоге получаю на каждый вызов по строке в b_cache_tag, все верно, но не понимаю зачем туда добавляются повторные, с теми самыми же id, которые там уже есть. Можно предположить, что для ускорения работы не осуществляется проверка на подобную запись, новая мода - тупо пишем.
Все бы еще ничего, если бы при очистке кэша b_cache_tag очищался, но нет, мои RegisterTag как там были после очистки так и остались.
Остальные же записи из стандартных компонентов так же разрастаются самостоятельно и не удаляются очисткой кэша, сейчас уже 25851 записей, при условии, что проект в разработке несколько месяцев и еще не запущен. Установлены последние бэты.

Интересно, а решена ли проблема сейчас?
Столкнулся с тем, что на не очень крупном проекте (около 1000 хитов/час) таблица b_cache_tag занимает уже 236 мб.

Этот запрос:

Дает следующий результат:

Но, например, папки "345" в "/bitrix/cache/s1/bitrix/catalog.section" нету.
Есть следующие директории:

Что все это может значить и что делать?

проблема будет возникать на действительно очень больших проектах. Наблюдал разрастание и до нескольких Гб.

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