Вставка в основную таблицу и в mat. view неатомарна. Но если использовать Replicated-таблицы для обеих и повторять вставку после любой ошибки, то данные будут корректно вставлены без дубликатов в оба места.

... удалено. Похоже poco флашит автоматом.

Вставка в основную таблицу и в mat. view неатомарна. Но если использовать Replicated-таблицы для обеих и повторять вставку после любой ошибки, то данные будут корректно вставлены без дубликатов в оба места.

А у меня сложилось впечатление, покрепленное опытом, что атомарна или почти. Ошибка вставки в MV приводит к откату вставки в основную таблицу. Исключение -- когда несколько некаскадных MV на одной таблице: если на момент ошибки какие-то MV уже обновились, то они не откатываются

Во всяком случае в рамках одной реплики. Остальные реплики (основая таблица и MV) догоняются полностью независимо

Вставка идёт сначала в MV, потом в основную таблицу. Если ошибка на этапе вставки в MV, то ничего не вставится.

Всем привет! есть возможность средствами КХ выстраивать запросы в очередь? есть органичение по кол-во конкурентных запросов. Есть ли у КХ средство из коробки или всегда будет лететь ошибка?

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

шуршит в фоне мержами

'max_memory_usage_for_user', 'max_memory_usage_for_all_queries'

+ 'max_memory_usage', 'max_bytes_before_external_group_by'

max_memory_usage выставлено, но чот по ощущениям выжрато весьма больше :)

max_memory_usage - это на один запрос

а ну да

У меня такая же ошибка тоже на вставках последняя версия выжраламвсю оперативу и сервер крашнулся по oom

Вставка идёт сначала в MV, потом в основную таблицу. Если ошибка на этапе вставки в MV, то ничего не вставится.

У меня получается наоборот, в основной таблице данных больше чем в MV. Ошибок при вставке нет. Получается данные в основную таблицу попали, а до MV не доехали. Когда не было реплик, вроде данные соответствовали, а с репликами что-то не получается добиться правильно работы MV

Коллеги, у меня в запросе есть условие WHERE category_id IN (:categoryIds), использую NamedParameterJdbcTemplate а можно как-то на уровне SQL переписать это условие, чтобы в случае, если в :categoryIds передавалось NULL, то это условие игнорировалось по сути, и в фильте запроса не было категории? ну то есть чтобы SELECT вывел по всем категориям?

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

Поставьте в users.xml в profiles/default <background_pool_size>2</background_pool_size> Может быть в будущем сделаем, чтобы сервер сам подстраивался под инсталляции с очень маленьким объёмом оперативки.

У меня получается наоборот, в основной таблице данных больше чем в MV. Ошибок при вставке нет. Получается данные в основную таблицу попали, а до MV не доехали. Когда не было реплик, вроде данные соответствовали, а с репликами что-то не получается добиться правильно работы MV

MV создана с Replicated движком?

@milovidov_an ну я бы не сказал, что 120gb - это очень маленький объем :)

@milovidov_an ну я бы не сказал, что 120gb - это очень маленький объем :)

Да, это явно не про ваш случай. Про Slach, у которого 4 GB.

Всем привет! есть возможность средствами КХ выстраивать запросы в очередь? есть органичение по кол-во конкурентных запросов. Есть ли у КХ средство из коробки или всегда будет лететь ошибка?

config.xml: <!— Maximum number of concurrent queries. —> <max_concurrent_queries>100</max_concurrent_queries> Также в users.xml в профиле пользователя можно прописать queue_max_wait_ms: /** The wait time in the request queue, if the number of concurrent requests exceeds the maximum. */

@milovidov_an ну я бы не сказал, что 120gb - это очень маленький объем :)

Ситуация такая. У вас выставлено ограничение max_memory_usage_for_all_queries. Некоторые SELECT-ы в сумме используют много памяти. Затем идёт INSERT. Сам INSERT расходует немного памяти, но в сумме на все запросы оперативки уже не хватает. Поэтому INSERT кидает исключение.

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

Решение: выставить также обычный max_memory_usage меньше, чем max_memory_usage_for_all_queries. Уменьшить максимальное количество запросов на пользователя - max_concurrent_queries_for_user. Включить внешнюю агрегацию - см. https://clickhouse.yandex/docs/ru/query_language/queries.html?highlight=max_bytes_before_external_group_by#id8

интересно, а линукс умеет пристрелить отдельный поток, а не приложение целиком при событии OOM?

Пристрелить отдельный поток, для программы на C++, не имеет смысла - кто же будет деструкторы вызывать - разблокировать mutex, освобождать память и т. п.

это да, конечно...

Если я правильно понимаю, это освободит только стек потока, что не очень много

в теории ведь можно добавить поток в отдельную cgroup

и наложить на нее ограничения памяти

но как это состыкуется с C++ - оооочень сложный вопрос

потоки имеют общее адресное пространство (процесса), сомневаюсь, что это вообще возможно

config.xml: <!— Maximum number of concurrent queries. —> <max_concurrent_queries>100</max_concurrent_queries> Также в users.xml в профиле пользователя можно прописать queue_max_wait_ms: /** The wait time in the request queue, if the number of concurrent requests exceeds the maximum. */

queue_max_wait_ms а эта настройка в доке не описана дефолтное значение у нее получается 0?

если бы ОС умела передать инфуормацию об этом в приложении - поидее было бы возможно

в бусте есть т.н. interruption point

когда приложение может прочесть уведомление и например пристрелить поток

и вызвать корректно освобождение занятых ресурсов конкретно этим потоком

Because this ability caused certain problems, the ability to independently manipulate the cgroup memberships of the threads in a process has been removed in cgroups v2

и вызвать корректно освобождение занятых ресурсов конкретно этим потоком

Адресное пространство - общее, у потока нет его ресурсов (кроме стэка)

MV создана с Replicated движком?

Да

эх, сколько развлечения удалили :)

queue_max_wait_ms а эта настройка в доке не описана дефолтное значение у нее получается 0?

По-умолчанию, 5 секунд.

Да

В таком случае я затрудняюсь сказать навскидку, какая возможна причина. Можно посмотреть в лог. Для каждого INSERT-а, при записи, пишется сообщения вида: <Debug> merge..inner.hits_timings2 (Replicated OutputStream): Wrote block 125579 with ID 17833449664338286632_166080607874846114, 116 rows И посмотреть на соответствия с обычной таблицей и MV.

Ок, попробую покопаться

Коллеги, у меня в запросе есть условие WHERE category_id IN (:categoryIds), использую NamedParameterJdbcTemplate а можно как-то на уровне SQL переписать это условие, чтобы в случае, если в :categoryIds передавалось NULL, то это условие игнорировалось по сути, и в фильте запроса не было категории? ну то есть чтобы SELECT вывел по всем категориям?

если вам не нужна фильтрация по id, то зачем вы ее добавляете в запрос?

ну там передается либо список ID шников, либо NULL и если NULL, то это значит вывести все категории

там - это где

и почему это не означает список из одного id, равного null

по-моему драйвера запросы особенно не парсят и вряд ли что-то в них удаляют.

Такое как-то можно починить? Сегодня уже 14 июня, а он все еще надеется... Part 20170606_20170606_238257_238365_21 is covered by 20170606_20170606_238257_238370_22 but should be merged into 20170606_20170606_238257_238372_22. This shouldn't happen often. Checking if anyone has part covering 20170606_20170606_238257_238372_22. Found all blocks for missing part 20170606_20170606_238257_238372_22. Will wait for them to be merged.