Добрый вечер. Вернусь с проблемой медленной вставки, хотел бы еще

уточнить момент.
У нас есть таблица(replacing), где хранятся данные по вставленным id, по этой таблице мы мониторим какие id уже вставлены, а какие нет из источника.
В таблице около 50 строк, в зависимости от таблицы в которую вставляем данные, берется нужный id и источник уже по нему загружает данные в КХ.
Так вот, так как у нас много вставок, эта таблица заполняется данными постоянно, как минимум несколько раз в секунду, и выбираются id оттуда через final.
И перед основными тормозами на вставке в другие таблицы, я вижу как вставка деградирует вставка и в эту маленькую таблицу, хотя вставляется туда всего несколько строк, но очень часто. И запросы на вставку в эту маленькую таблицу оканчиваются одновременно с тем как и заканчивается вставка в основные большие таблицы.

Вопрос, может ли этот инсерт в маленькую таблицу деградировать все остальные запросы, и если да, то как ускорить?
PS: обычно в эту таблицу вставки меньше 100мс

так замените select final на argmax / или max

типа вы делаете insert table select .... from table final во многих потоках и оно зависает? и таблица Replicated и сколько реплик? вставка на разных репликах?

нет если говорить про маленькую таблицу, то я делаю insert into values() их может быть 5-15 в секунду. select id from table final редкий Таблицаа replicated, 3 реплики. вставка только в одной реплике.

Суммирую . Т.е. вы делаете 15 вставок в сек. по одной строке в таблицу в которой 50 строк и иногда инсерты работают очень долго?

абсолютно так

точнее так, что пытаюсь выяснить взаимосвязь этих вставок в маленькую таблицу и много вставок в большую таблицу, может ли медленный инсерт на маленькую трогать и инсерт на другую таблицу. В этот момент селектов в маленькую таблицу нет

Вот пример как происходит, есть вставки в маленькую таблицу, сначала они быстрые, потом они медленные, параллельно с этим приходят вставки в большую таблицу, они медленные, далее отпускает медленную вставку в маленькую таблицу одновременно с остальными, и дальше все идет нормально - без деградации(вставку в маленькую таблицу быстрые и в большую относительно быстрые) ПС: количество вставляемых строк так разбито, это все для теста, если сгруппировать их в один инсерт в несколько десятков тысяч строк, то все тоже самое. Как я понимаю, все начинается с деградации вставки в маленькую таблицу.

это тестовая система? что если таблицы не replicated ? никто не знает что это за проблема и не получается ее воспроизвести

another table насколько широкая? сколько там полей?

нет, прод система( с nonreplicated попробуем протестировать

another_table - другие таблицы, их 5 штук полей от 3 до 5, в одной 25 полей. Да, еще добавлю, что на big_table есть 2 MV

и во что упираетесь? в диск, память или проц?

ни во что, памяти навалом, проц курит все время 2-3% нагрузка, диск аналогично.

большая таблица - реплейсинг, а маленькая таблица - лог?

обе replicatedreplacing

т.е. вы делаете вставки в большую таблицу, на которой висит мат вью и переливает эти же сырые строки в маленькую таблицу, в которой периодически запускается схлопывание десятков тысяч сырых строк в 50 агрегированных и в этот момент у вас происходит деградация вставки в маленькую таблицу?

нет, они не связаны никак. маленькая таблица содержит всего 3 поля и 50 строк. туда заполняются id последних вставленых значений, на случай падения КХ/сервисов/и прочего. а большая таблица содержит уже больше 25 полей. МВ переливает данные из большой в две другие таблицы агрегаты.

т.е. маленькая таблица никак не связана другими ни на ней нет мат вью, ни у других мат вью она не указана как целевая? она вообще сбоку но периодически деградирует вставка и при это сервер не нагружен? а как в этот момент загружен зукипер?

Да, она сбоку, на ней есть view с final на которую прикручен словарь, и редко(пару раз в час) используется этот словарь. Да, периодически деградирует вставка. Памяти много свободной, максимум CPU idle time 85%. LA максимум 5, на 36 физ ядрах. ЗК avg_latency 0мс

echo mntr | nc localhost 2181 zk_version 3.5.6-c11b7e26bc554b8523dc929761dd28808913f091, built on 10/08/2019 20:18 GMT zk_avg_latency 0 zk_max_latency 2458 zk_min_latency 0 zk_packets_received 5343218233 zk_packets_sent 5444632907 zk_num_alive_connections 3 zk_outstanding_requests 0 zk_server_state follower zk_znode_count 219655 zk_watch_count 216 zk_ephemerals_count 426 zk_approximate_data_size 40895751 zk_open_file_descriptor_count 61 zk_max_file_descriptor_count 500000

max latency - две с половиной секунды - это ок? больше полсекунды гуглится только у тех у кого были проблемы с зукипером.

тут за все время же, с момента запуска

да, можно рестарнатуть и проверить при фризах :) но это вряд ли, но и идей кроме попробовать другую версию кх нету.

там же альтерами старые строки не удаляются надеюсь?

alter вообще нет replacing таблицы, там нет вообще удалений

свежий комент по похожей проблеме как у вас https://github.com/ClickHouse/ClickHouse/issues/26755#issuecomment-920125629

тоже мониторите?

проблемы нет, но интересно чем закончится)

кстати тоже бывает, что просто начинает репликация отставать на таблицах меньше 1К строк, которые пополняются пару раз в день. Репликация отстает всегда на похожее кол-во времени

Дополню информацию, в system.part_log есть MergeParts по 4-30 сек. Это следствие медленной вставки, или причина? И как можно ускорить мердж, все настройки по мерджу дефолтные.