Телеграмм чат группы clickhouse

Вставляю 2к строк, размер суммарный мегабайт может 20 у пачки, в одном из полей есть json

22:46пожаловаться #1

DC

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

2021.02.13 19:43:24.322758 [ 10895 ] {} <Error> auto DB::IBackgroundJobExecutor::jobExecutingTask()::(anonymous class)::operator()() const: Code: 241, e.displayText() = DB::Exception: Memory limit (total) exceeded: would use 10.56 GiB (attempt to allocate chunk of 17416376 bytes), maximum: 10.55 GiB: (avg_value_size_hint = 1024, avg_chars_size = 1219.2, limit = 8192): (while reading column json)

Какая версия? Это исправляли. Можно ещё insert_parallel_parsing=0

22:58пожаловаться #2

m

Denny Crane [not a Yandex bot]

Какая версия? Это исправляли. Можно ещё insert_parallel_parsing=0

20.12.3.3

22:58пожаловаться #3

m

Исправляли? То есть был баг связанный с json? Или с вставкой? insert_parallel_parsing опция на уровне клиента или это можно в xml прописать?

22:59пожаловаться #4

DC

Исправляли? То есть был баг связанный с json? Или с вставкой? insert_parallel_parsing опция на уровне клиента или это можно в xml прописать?

Просто трекер неправильно считал расход. Но кажется в этой версии уже исправили. Сколько в Линуксе top память показывает REE/RSS у процесса кх?
Опция у клиента. Вы кх клиентом вставляете? В случае кх-клиента парсинг делает клиент.

23:10пожаловаться #5

m

Denny Crane [not a Yandex bot]

Просто трекер неправильно считал расход. Но кажется в этой версии уже исправили. Сколько в Линуксе top память показывает REE/RSS у процесса кх?
Опция у клиента. Вы кх клиентом вставляете? В случае кх-клиента парсинг делает клиент.

Вставляет JDBC драйвер.

RES\RSS в районе 1500-2500мб максимум, в зависимости от ситуации, когда инзерт происходит память скажем 700мб, потом она увеличивается медленно (другие селекты, все селекты собственно тоже обрываются если этот запрос в процессе (и его кстати видно в system.merges и сам мердж происходит очень долго для 2к строк, секунд 10-12 и завершается всегда фейлом не вставив данные)

23:13пожаловаться #6

DC

Вставляет JDBC драйвер.

RES\RSS в районе 1500-2500мб максимум, в зависимости от ситуации, когда инзерт происходит память скажем 700мб, потом она увеличивается медленно (другие селекты, все селекты собственно тоже обрываются если этот запрос в процессе (и его кстати видно в system.merges и сам мердж происходит очень долго для 2к строк, секунд 10-12 и завершается всегда фейлом не вставив данные)

Можно в профиле default тогда выключить параллеьный парсинг. Ну и можно поставить коэффициент 2 чтобы total не срабатывал

23:17пожаловаться #7

m

Это надо сделать для каждого шарда я так понимаю?

23:17пожаловаться #8

DC

Это надо сделать для каждого шарда я так понимаю?

Да. В которых вставляете
Можно и в jdbc в url попробовать. Кажется должно работать.

23:19пожаловаться #9

m

Ок, а есть варик мне просто обновится до 21.2.2.8 залетает из дебиан репозитоория — там уже это поправлено ?

23:20пожаловаться #10

DC

Ок, а есть варик мне просто обновится до 21.2.2.8 залетает из дебиан репозитоория — там уже это поправлено ?

Попробуйте сначала 20.12.5.18

23:22пожаловаться #11

m

Ок, момент

Tatiana in ClickHouse не тормозит

23:22пожаловаться #12

2021 February 14

T

Slach

=\ а если не использовать то при Atomic люди удаляют таблицу, и снова создают... и обламываются "потому что такая уже есть"

Лучше один раз понять, что такое Atomic, чем напихать uuid в zpath и через некоторое время обломиться еще раз.
Есть же способы удалить таблицу синхронно.

00:32пожаловаться #13

D

Лучше один раз понять, что такое Atomic, чем напихать uuid в zpath и через некоторое время обломиться еще раз.
Есть же способы удалить таблицу синхронно.

можете для тех кто в ЗК не копенгаген прояснить, чем плох uuid в zpath для zk?

Tatiana in ClickHouse не тормозит

02:17пожаловаться #14

T

Dj

можете для тех кто в ЗК не копенгаген прояснить, чем плох uuid в zpath для zk?

Я знаю, что у реплик zpath должен быть одинаковый.
А откуда в макрос uuid значение подставляется, я не знаю.
Если вы дропнули реплику, и создаете новую, что будет?

02:20пожаловаться #15

D

Я знаю, что у реплик zpath должен быть одинаковый.
А откуда в макрос uuid значение подставляется, я не знаю.
Если вы дропнули реплику, и создаете новую, что будет?

в макрос UUID из таблицы, из UUID таблицы по логике.
как я понял при создании on cluster - Это автоматом делается.
при под-реплике, да, вы должны брать часть UUID из ДДЛ другой текущей реплики...

Tatiana in ClickHouse не тормозит

02:24пожаловаться #16

T

Dj

в макрос UUID из таблицы, из UUID таблицы по логике.
как я понял при создании on cluster - Это автоматом делается.
при под-реплике, да, вы должны брать часть UUID из ДДЛ другой текущей реплики...

Вот я и говорю, при неаккуратном использовании можно не мало граблей насобирать.
Мне не нравится утверждение, что uuid в zpath использовать "НАДО"

02:27пожаловаться #17

D

Вот я и говорю, при неаккуратном использовании можно не мало граблей насобирать.
Мне не нравится утверждение, что uuid в zpath использовать "НАДО"

да вряд ли, максимум новая реплика не будет синхронизироватся, и все.
мне например больше не нравится что нет макроса {database} по умолчанию во всех мануалах... там намного больше шансов нафакапить с одинаковыми путями в разных базах на одинаковых таблицах

02:30пожаловаться #18

D

Вот я и говорю, при неаккуратном использовании можно не мало граблей насобирать.
Мне не нравится утверждение, что uuid в zpath использовать "НАДО"

так, что тут имхо именно надо
вместо:
/clickhouse/tables/{layer}-{shard}/table_name
такое
/clickhouse/{clustername}/tables/{shard}/{database}/{table}/{uuid}, {replica}

02:33пожаловаться #19

D

но вообще с приходом default_replica_path - то что вы говорите становится риском. имхо можно фичу сделать для забора УУИД с другой реплики по remote по названию таблицы при создании.