Добрый день. В Clickhouse скопилась очередь операций. В system.replication_queue 63

записи, операции типа TTL_DELETE. В колонке postpone_reason сказано следующее:


Not executing log entry queue-xxx for part xxx because 2 merges with TTL already executing, maximum 2.


Судя по всему, очередь скопилась из-за того, что TTL_DELETE мёрдж по одной из таблиц выполняется очень долго. Что можно сделать?

Есть возможность увеличить число параллельно выполняющихся ttl-операций? Что влияет на скорость ttl-операции? Должна ли помочь настройка ttl_only_drop_parts?

Привет, ни у кого похожей ситуации не возникало?

Добрый день! Столкнулся с такой же проблемой, у вас получилось ее решить тогда?

Очередь постепенно рассосалась, так и решили :) Можно подумать в сторону того, почему TTL_DELETE выполняется так долго. У нас это связано, скорее всего, с большим количеством условий TTL WHERE и кодеком сжатия ZSTD(3). Если мы сократим количество TTL условий или поменяем сжатие колонки, по которой выполняется TTL DELETE, на gzip, тогда TTL мердж должен будет выполняться быстрее и очередь не будет забиваться.

у нас вообще не выполняется похоже и куда копать не понимаем причем только на одной реплике из 3х такая проблема

Ошибки в логах есть?

чего-то связанного с этим не нашел

Можно глянуть прогресс слияния, выполнив запрос: select * from system.merges m;

результат пустой )

в общем там появляются мержи REGULAR а TTL_DELETE нет

Чем реплика отличается от других? Сколько у вас таблиц с ttl?

так вроде ничем ) по ресурсам одинаково, настройки одиаковые не могу точно ответить, в очереди видел только 2 можно как-то достоверно узнать это?

Посмотрите чему равно на других серверах max_number_of_merges_with_ttl_in_pool SELECT * FROM system.merge_tree_settings WHERE name like '%ttl%'

везде 2

это новая реплика? С чего проблема началась?

Нет все реплики одного возраста, мы просто начали получать Алерт с нее что диска мало, первоисточник проблемы не понятен

ну увеличьте этот парметр до 10 например.

я пытался уже, но почему-то кликхаус его не принимает, он в контексте merge_tree настраивается?

Да. Перезагрузка нужна

это сложно ))

Тогда увеличьте прямо у таблицы хотя не факт что поможет

это в SETTINGS? через alter?

Да в доке есть пример

он залочит таблицу? она почти 2ТБ наверное это тоже будет болезненно

спасибо, попробую

В system tables есть поле create_table что-то там , поищите в нем ilike "%ttl%' чтобы узнать сколько у вас таблиц с ttl

а что даст ответ на этот вопрос?

Если там 1 то это одна проблема и надо разбираться с X, если там 18000 это другая проблема и надо крутить Y

Их не много, хорошо я попробую собрать статистику

15 таблиц из них 5 системные *_log

На всех репликах одинаково? если их 15 то конечно 2 ttl одновременно может не хватать. Сделайте 10.

одинаково попробуем, запланировали рестарт когда нагрузка низкая будет просто очередь вообще не двигается, сейчас висят задания со вчерашнего дня когда я таблицу пересоздал 2023-05-22 16:33:11, 20230508_106536_106536_1 и она как была первой в очереди так и остается

остальные ttl параметры тоже такие? Ttl просыпается раз в 4 часа по дефолту, конечно на 15 ttl может не хватить 2х

да, ноды полностью идентичны еслиб не хватало воркеров то их анверное не хватало бы на всех нодах

в общем ап воркеров до 8 штук + рестарт помог спасибо!