Привет всем. Может, кто сталкивался с ограничением мерджей?

В одной таблице в партиции уже 1000 партов, иногда в логах вижу задержку вставки на 8мс, больше ничего необычного не вижу, партиции небольшие, может есть какие-то параметры?

сколько из этих партов active ? как вставляете какими кусками? задержка это походу у вас Throttling SELECT * FROM system.events WHERE event ILIKE '%inserts%';

Все активные, если не только активные, то 1100-1200, Куски по 5-8м строк, строки по 150 байт примерно,

ILIKE не нашел, версия 19.15.4, но SELECT * FROM system.events WHERE event LIKE '%nserts%' ┌─event──────────────────────┬─value─┬─description──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ DelayedInserts │ 3269 │ Number of times the INSERT of a block to a MergeTree table was throttled due to high number of active data parts for partition. │ │ DelayedInsertsMilliseconds │ 14336 │ Total number of milliseconds spent while the INSERT of a block to a MergeTree table was throttled due to high number of active data parts for partition. │ └────────────────────────────┴───────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Даже ст тротлингом вставки идут , не отставая, почему парты не смердживаются, не ясно, всера было 400 кусков активных, а сегодня выросло и не падает, хотя ресурсы(диск, проц, память, воркеры) - есть, может какой-то лимит сверху говорит, мерджить мелкими пачками или что-то ещё?

max_bytes_to_merge_at_max_space_in_pool 161061273600 больше этого размера парта мерджи не будут происходить так же мерджи не будут происходить на больших партах если меньше 8 (number_of_free_entries_in_pool_to_lower_max_size_of_merge) потоков свободно в пуле

max_bytes_to_merge_at_max_space_in_pool - нет такой настройки, number_of_free_entries_in_pool_to_lower_max_size_of_merge - это имя метрики?

select * from system.merge_tree_settings s where name like '%merge%';

SELECT * FROM system.merge_tree_settings WHERE name LIKE '%merge%' ┌─name──────────────────────────────────────────────────────┬─value─────────┬─changed─┬─description────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ max_bytes_to_merge_at_max_space_in_pool │ 4394967296000 │ 1 │ Maximum in total size of parts to merge, when there are maximum free threads in background pool (or entries in replication queue). │ │ max_bytes_to_merge_at_min_space_in_pool │ 1048576 │ 0 │ Maximum in total size of parts to merge, when there are minimum free threads in background pool (or entries in replication queue). │ │ max_replicated_merges_in_queue │ 16 │ 0 │ How many tasks of merging and mutating parts are allowed simultaneously in ReplicatedMergeTree queue. │ │ number_of_free_entries_in_pool_to_lower_max_size_of_merge │ 8 │ 0 │ When there is less than specified number of free entries in pool (or replicated queue), start to lower maximum size of merge to process (or to put in queue). This is to allow small merges to process - not filling the pool with long running merges. │ │ prefer_fetch_merged_part_time_threshold │ 3600 │ 0 │ If time passed after replication log entry creation exceeds this threshold and sum size of parts is greater than "prefer_fetch_merged_part_size_threshold", prefer fetching merged part from replica instead of doing merge locally. To speed up very long merges. │ │ prefer_fetch_merged_part_size_threshold │ 10737418240 │ 0 │ If sum size of parts exceeds this threshold and time passed after replication log entry creation is greater than "prefer_fetch_merged_part_time_threshold", prefer fetching merged part from replica instead of doing merge locally. To speed up very long merges. │ │ enable_vertical_merge_algorithm │ 1 │ 0 │ Enable usage of Vertical merge algorithm. │ │ vertical_merge_algorithm_min_rows_to_activate │ 131072 │ 0 │ Minimal (approximate) sum of rows in merging parts to activate Vertical merge algorithm. │ │ vertical_merge_algorithm_min_columns_to_activate │ 11 │ 0 │ Minimal amount of non-PK columns to activate Vertical merge algorithm. │ │ min_merge_bytes_to_use_direct_io │ 10737418240 │ 0 │ Minimal amount of bytes to enable O_DIRECT in merge (0 - disabled). │

│ merge_with_ttl_timeout │ 86400 │ 0 │ Minimal time in seconds, when merge with TTL can be repeated. │ └───────────────────────────────────────────────────────────┴───────────────┴─────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

select * from system.metrics m where metric like '%Background%Task%'; смотрите сколько у вас активных мерджей и других тасков в пуле

так КХ искусственно тормозит инсерты https://clickhouse.tech/docs/ru/operations/settings/merge-tree-settings/#max-delay-to-insert

SELECT metric, value FROM system.metrics WHERE metric LIKE '%Background%' ┌─metric───────────────────────────────────┬────────value─┐ │ BackgroundPoolTask │ 13 │ │ BackgroundSchedulePoolTask │ 0 │ │ MemoryTrackingInBackgroundProcessingPool │ -2915439214 │ │ MemoryTrackingInBackgroundSchedulePool │ -37714090936 │ └──────────────────────────────────────────┴──────────────┘

если тасков 40. проблемы быть не должно.. даже не знаю, может версия старая/баги

ещё может быть что места на диске нет. Смотрите в логи, там увидите ошибки почему мерджи не идут

Место есть и КХ это видит: <Debug> DiskSpaceMonitor: Reserving 1.00 MiB on disk default, having unreserved 4.85 TiB.

А по какому слову искать, в логе ошибок не вижу: по этой таблице идут мерджи: 2021.01.26 17:47:53.456366 [ 41 ] {} <Debug> default.graphite_week2 (MergerMutator): Merging 6 parts: from 20210125_37176_37176_0 to 20210125_37181_37181_0 into tmp_merge_20210125_37176_37181_1 2021.01.26 17:47:53.456738 [ 41 ] {} <Debug> default.graphite_week2 (MergerMutator): Selected MergeAlgorithm: Horizontal

ну попробуйте "Not executing log entry"

Есть такие: 2021.01.26 18:04:29.154304 [ 37 ] {} <Debug> default.graphite_week2 (ReplicatedMergeTreeQueue): Not executing log entry for part 20210111_177490_178692_422 because another log entry for the same part is being processed. This shouldn't happen often. и 2021.01.26 08:42:37.323698 [ 30 ] {} <Debug> default.graphite_week2 (ReplicatedMergeTreeQueue): Not executing log entry MERGE_PARTS for part 20210125_29062_29098_2 because source parts size (1.20 GiB) is greater than the current maximum (304.36 MiB). - это когда воркеры заканчивались

ну значит workerы все же заканчиваются, несмотря на то, что их 40 =) посчитайте в логах по дням как часто вы видите такое, и участилось ли это - скорее всего из-за этого. ещё есть вариант вас тупо не поспевают мерджи за вставками (либо вставок стало сильно больше, либо ещё чего)

Воркеры заканчивались утром, с 11 часов утра половина свободна, вставки мы разряжаем, вставляя реже, но пачками крупнее