Можно прям так truncate cache_page (шутка). Но а если серьёзно, думаю что-то похожее можно сделать.

Вот, кстати, выдержка из книги, на которую я выше ссылку дал. стр. 159
Далее вольный перевод из google translate

Как упоминалось ранее в этой главе, очень важно выделить достаточно места в Memcached, чтобы у вас не было постоянной нехватки памяти для хранения кеша и вынуждали Memcache вытеснять действительные элементы кеша для хранения новых элементов. Большинство дистрибутивов Linux поставляют пакеты Memcached с размером корзины по умолчанию 32–64 МБ.

Как правило, это слишком мало для сайтов Drupal, так как многие сайты могут содержать несколько гигабайт кэшированного содержимого. При первой настройке Memcached вы можете угадать свои требования к размеру, посмотрев на размер ваших таблиц кэша в MySQL - хотя это не будет точным представлением размера, необходимого для хранения ваших элементов кеша в Memcache, он может предоставить как минимум приблизительная цифра, чтобы вы начали. Оттуда вы можете наблюдать за использованием Memcache с помощью встроенной команды stats или раздела статистики, предоставляемого модулем Memcache_admin, или отслеживать его с помощью чего-то вроде Munin или Cacti. Если вы начинаете видеть почти полное пространство или большое количество выселений, то вам следует увеличить объем памяти
выделение для Memcached.
Возможно, вы заметите, что выселение происходит до того, как экземпляр Memcached использует 100% выделенной памяти. Это связано с тем, что Memcached выделяет пространство в различных плитах, где каждая плита используется для хранения элементов определенного диапазона размеров - например, одна плита будет хранить элементы, требующие 1000–2000 байтов, другая плита будет хранить элементы, которым требуется 2 001–4 000 байтов. и т. д. Итак, если у вас есть много элементов с одинаковым размером, то можно заполнить плиту, в то время как общий экземпляр Memcached все еще имеет свободное место в других плитах. Хотя вы можете регулировать приращения размера выделения плиты, как правило, это не очень хорошая практика; за исключением очень особых случаев, обычно лучше просто выделить для Memcached больше памяти.

Один раз встречал такое из-за кастомного кеш контекста
Почти каждый коннект был уникальным

У Кеша есть такой скил, но не у базы

Но вообще стоит посмотреть чем засирается, может где-то query string множит кеш беспощадно

Кстати да, ютм-метки всякие может подсирают в кэш

++ именно

Интересно, а не пользуется ли кто редмайном для трекинга?

Очень редко, с трекинг чего? Времени

Ну видишь, я попал немного в машину времени, унесло на 10 лет назад. Пантеон, редмайн, ландо, вот это всё.
С редмайном оказался абсолютно неразрешимым вопрос пристёгивать к тикету ссылки на коммиты, как это сто лет уже делает джира. Это правда невозможно?

Можно, но гит нужно монтировать рядом, чтобы он мог читать

ну то есть нельзя, потому что гит на гитхабе.
Есть какие-то плагины, которые синхронизируют локальный гит с гитхабом, точнее наоборот, но это хрень какая-то. И ссылки потом будут на гит, который рядом, нужно дальше какую-то затычку делать.
Неужели никто не работает гитхаб+редмайн

Я давно искал и в итоге мы на гитлаб перешли)

На гитлаб в плане репы, трекера, или и того и другого и ещё CI впридачу?

Да, всё в одном и репы докера

https://jobs.drupal.org/therefore/job/14717
Как бы вы перевели заголовок этой вакансии?

Безголовый Drupal разработчик? 😂

Получается так.

Именно так, а не "безголовый разработчик Drupal";)

Так вроде смысл не поменялся.