pgrep -f clickhouse-server | while read i; do echo -17 > /proc/$i/oom_adj; done ;)

это чего? исключили процесс так?

Спасибо то что надо https://pesin.space/blog/2009/06/%D0%BA%D0%B0%D0%BA-%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B8%D1%82%D1%8C-%D0%B8-%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B8%D1%82%D1%8C-%D0%B2%D0%B5%D1%80%D0%BE%D1%8F%D1%82%D0%BD%D0%BE%D1%81/

Virus ?

Круто:)

Отключиль OOM киллер и думаете все? Хехе, амазон перегрузил инстанс

надо как-то КХ ограничить все таки

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

Своп нельзя. Будет очень плохо.

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

вы извините за глупые предложения-вопросы.

Алексей, а чем плохо? Машина хоть не умрет когда память кончится. или на работу сильно влиять будет?

Своп нельзя. Будет очень плохо.

Для эксплуатации клика желательно swapoff?

Нормальные вопросы. Сначала стоит посмотреть, что расходует оперативку под нагрузкой. Два варианта - запросы и мержи. Если запросы - это видно в SHOW PROCESSLIST. Если мержи - это видно в SELECT * FROM system.merges. Для запросов имеет смысл ограничить каждый конкретный запрос, сумму на user-а и все запросы: max_memory_usage max_memory_usage_for_user max_memory_usage_for_all_queries А также ограничить количество одновременных запросов: max_concurrent_queries_for_user и в конфиге, max_connections Если некоторые запросы слишком сложные/плохие и долго выполняются, то ограничить всеми способами эти запросы. Способов полно: max_execution_time, force_index_by_date, max_rows_to_read и т. п.

Для эксплуатации клика желательно swapoff?

Не обязательно swapoff, главное - не использовать swap по факту.

Следует иметь ввиду, что настройки вида max_memory_usage_for_all_queries работают сравнительно грубо: даже если совсем маленький запрос хочет выделить память так что будет превышена настройка - кидается исключение. Поэтому стоит поставить, для примера: max_memory_usage - 2 GB max_memory_usage_for_user - 10 GB max_memory_usage_for_all_queries - 25 GB на машине с 32 GB оперативки.

Алексей, а с ошибкой "<Error> HTTPHandler: Code: 244, e.displayText() = DB::Exception: Unexpected ZNODEEXISTS while adding block 300394 with ID 15296119188113654211_8820013648559882837: node exists, e.what() = DB::Exception, Stack trace:" случаем не возникло идей что может быть и что делать? :)

Vitaliy Lyudvichenko пытался помочь, но проблему так и не решили.

Алексей, а с ошибкой "<Error> HTTPHandler: Code: 244, e.displayText() = DB::Exception: Unexpected ZNODEEXISTS while adding block 300394 with ID 15296119188113654211_8820013648559882837: node exists, e.what() = DB::Exception, Stack trace:" случаем не возникло идей что может быть и что делать? :)

Не возникало идей. Какая версия сервера, используется ли insert_quorum?

insert_quorum - нет, версия 1.1.54236. пробывали 1.1.54245 - вообще все завалило сообщениями про медленый мерж

пришлось откатыватся

11 rows in set. Elapsed: 0.016 sec. :) SHOW PROCESSLIST 11 это батчей по 50000 (600 колонок (скоро исправлю))

в мержах пусто

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

insert_quorum - нет, версия 1.1.54236. пробывали 1.1.54245 - вообще все завалило сообщениями про медленый мерж

Очень интересно. Может быть как-то связано с откатом на предыдущую версию. Возникает при вставке одного куска постоянно? И почему на новой версии возникла проблема тоже требует разбирательств. У нас эта версия уже пару недель работает. Знаем только про проблему с оперативкой на вертикальный мерж, которая влияет только если у вас много данных в узких таблицах (в последней testing версии исправлено).

11 rows in set. Elapsed: 0.016 sec. :) SHOW PROCESSLIST 11 это батчей по 50000 (600 колонок (скоро исправлю))

Это значит, что у вас в processlist только INSERT-ы?

да

пока только вствка из кафки

Тогда совет ограничить пользователей не сильно релевантен, так как пользователи - это вы сами. То есть, если ограничите настройками, то есть шанс, что INSERT-ы вообще не будут работать. Попробуйте уменьшить количество одновременных INSERT-ов на своей стороне.

я то уиеньшу, но как мне на моей стороне знать как уменьшать и на сколько? мне бы от КХ в качестве ответа что-то типа: я тут на последнем дыхании на тебе пока ошибку 321 (типа я под нагрузкой выполнить не могу) я бы тогда реагировал на такое на своей стороне

Тогда max_memory_usage_for_user, max_memory_usage_for_all_queries вполне подойдут. Правда ещё особенность - это ограничивает только запросы, но не background мержи. Мержей по-умолчанию до 16 штук одновременно и для машины с 32 GB оперативки это может быть многовато. Уменьшить можно настройкой background_pool_size в профиле default. Желательно не уменьшать ниже чем 4.

уже сделал, спсб max_memory_usage_for_all_queries поставил в 20gb и пока держится. понятно что как тольо подключатся мержи и чтение придется пересмотреть настройки клево что они есть!

пока только вствка из кафки

если из кафки то это самый вменяемый способ, мы пишем в кафку, но в КХ вычитываем из неё и сбрасываем поток событий либо раз в 2 секунды (всё что накопилось) либо если событий более N

но не более 1 раза в секунду

И ещё по поводу перформанса (go driver): * добавили тип UUID (https://github.com/kshvakov/clickhouse/blob/master/clickhouse_test.go#L870) * для Go можно сохранять ipv4/v6 в FixedString(16) (https://github.com/kshvakov/clickhouse/blob/master/clickhouse_test.go#L912) * добавили конвертацию int в time (https://github.com/kshvakov/clickhouse/commit/aae9e4a9fa09c2e6942e67e8831351485dca74b7)

@kshvakov супер!!! Спасибо)

Отлично! Очень быстро развивается этот драйвер.

поделился с командой :) у нас своим костыли были для этого, выпиливать будем :)

Кстати к вопросу о распределённых DDL. В моём случае не взлетело - на всех серверах distributed_ddl установлен, при попытке прогнать запрос, клиент висит 2 минуты и отваливается. В зукипере эти транзакции видны, но никто их не применяет.

Есть известная недоработка - если в описании кластера имена хостов указаны не так, как выдаёт hostname -f на самих серверах, то не работает. Это не ваш случай?

поделился с командой :) у нас своим костыли были для этого, выпиливать будем :)

ну, Marek Vavruša уже есть доступ на коммит )))

ага, он самый, он у нас главный по Кликхаусу)

)))

Снова вопрос про вью, но без вложенных джойнов. создали такую вью: CREATE MATERIALIZED VIEW default.AggregatedEvent ENGINE = AggregatingMergeTree(date, (hour, eventId, gid1, gid2, gid3, date), 8192) AS SELECT toStartOfHour( toDateTime( time * 0.001 ) ) hour eventId, gid1, gid2, gid3, any(date) date, countState() count, uniqCombinedState(ufa) AS unique FROM ( SELECT uid, time, eventId, date FROM Event ) ANY LEFT JOIN ( SELECT id uid, gid1, gid2, gid3, ufa FROM Init ) USING uid GROUP BY hour, eventId, gid1, gid2, gid3; Нагрузка выросла просто катастрофически Может быть мы просто не умеем их готовить?

при том, что нагрузки нет особой. Видно что-то не так делаем

На каждый INSERT будет выполняться указанный запрос, с куском данных подставленным вместо таблицы Event. Возможно, что нагрузка из-за JOIN-а. Для выполнения JOIN-а, на каждый INSERT, будут читаться данные SELECT id uid, gid1, gid2, gid3, ufa FROM Init и формировать хэш-таблицу в оперативке. На практике мы не используем MAT. VIEW с JOIN-ами.

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

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

Можно приджоинивать необходимые данные на стороне клиента при вставке в основную таблицу?

На каждый INSERT будет выполняться указанный запрос, с куском данных подставленным вместо таблицы Event. Возможно, что нагрузка из-за JOIN-а. Для выполнения JOIN-а, на каждый INSERT, будут читаться данные SELECT id uid, gid1, gid2, gid3, ufa FROM Init и формировать хэш-таблицу в оперативке. На практике мы не используем MAT. VIEW с JOIN-ами.

на каждую запись в insert'e? или если писать сильно реже и больше данных, все стать сильно лучше может? Ну теоретически пока можно, но это лишнее место, а потом вдруг еще что-то захочется добавить) там на 15 ивентов 1 Init где-то

на каждую запись в insert'e? или если писать сильно реже и больше данных, все стать сильно лучше может? Ну теоретически пока можно, но это лишнее место, а потом вдруг еще что-то захочется добавить) там на 15 ивентов 1 Init где-то

На каждый батч.

Вобщем то проблема о которой я писал была на уровне транспорта. Возможно какой то баг в curl, которые не вызывает хендел повешенный на CURLOPT_READFUNCTION и поэтому запросы больше 1mb впринципе не уходили, если пользоваться CURLOPT_INFILE, то все ок

Всем привет, а кто-нить хранит сырые данные в кликхаусе? И если да - то у нас например, 30кк в день строк уже не получается вытащить горизонтально (даже с лимитами). То есть как "строки" - без агрегаций. Я понимаю, это задача не для аналитической БД, но все же? Если не в КХ храните, то может еще где-то?

Думаю надо ставить вопрос не "где", а "для чего"?

как вы дальше эти сырые данные планируете использовать?

Всем привет, а кто-нить хранит сырые данные в кликхаусе? И если да - то у нас например, 30кк в день строк уже не получается вытащить горизонтально (даже с лимитами). То есть как "строки" - без агрегаций. Я понимаю, это задача не для аналитической БД, но все же? Если не в КХ храните, то может еще где-то?

Рискну предположить, что для хранения совсем сырых данных в виде "как есть" предложат hadoop :)

чтобы если что из него выбрать данные и впихнуть в базу после пересчета или правки

как вы дальше эти сырые данные планируете использовать?

Вытаскивать постранично каждую запись

например экспорт кликов

То есть аткже отфильтровать по ключам, по дате.

Нашел )

всем привет, а никто не сталикавлся с периодической ошикбой: Caused by: org.apache.http.NoHttpResponseException: clickhouse2.tenet:8123 failed to respond ?

при запросах из jdbc драйвера

Сталкивался. Проследил до httpclient, как исправить там не нашел. Пришел к выводу что наблюдается когда: - post запрос chunked, т.е. тело не имеет заранее известного размера - поток, который поставляется в тело запроса, получается медленно, т.е. происходит таймаут между вызовом execute и моментом когда из потока наберется достаточно данных чтобы отправить первый чанк. В моем случае помогла буфферизация части потока данных перед отправкой запроса.

а можно по-подробнее про буферизацию?

и с настройками httpclient не игрались?

а можно по-подробнее про буферизацию?

Есть источник данных, который их отдает медленно, потом делаю потоково инсерт в кликхаус (sendStream()). Соответственно загружаю некоторый объем данных сначала в буффер, а потом в инсерт передаю склеенный поток из буффера(который уже в памяти и будет передан в инсерт быстро) и оставшейся части потока. Это все относится к sendStream в драйвере. Если у вас ошибка возникает в другом методе - интересно узнать кейс. С настройками пробовал, но там скорее надо сам код httpclient вычитывать и разбираться какие настройки могут подойти если есть. (я когда разбирался подходящих настроек там не нашел)

а насколько медленно он их отдает?

По поводу буффера для инсерта вроде все понятно, спасибо. Но ошибка воспроизводится еще и на client.execute (в методе getInputStream) при select запросах и там тела много не бывает по идее. И еще вопрос, есть ли способ простого воспроизведения данной ошибки? Если да, то поделитесь, пожалуйста. Хочу поиграться с этим и разобраться - может придумаю что-то

и да запросы по длине не большие

Кажется я эти эксперименты потерял. Но суть была такая - делал Enumeration, который через некоторое время (несколько секунд) выдавал несколько строчек в виде ByteInputStream, потом преобразовывал его потоково в один SequenceInputStream и делал insert, глядя на -Djavax.net.debug Если есть воспроизводимые отделяемые кейсы по select - можно их в задачу на github приложить или в pull request. По скорости: Насколько я помню, нужно было около килобайта за socketTimeout успеть передать.

надо передать больше чем буфера уровнем ниже за время таймаута

Я понял, попробую поэксперементировать, спасибо! А по поводу select, в том и проблема, что ситуация возникает рандомно и пока никаких зависимостей не наблюдаю. Если что-нибудь придумается или будут конкретные запросы, то конечно создал pull request. Спасибо за информацию :)

в целом оптимальнее накапливать данные и раз в N минут сливать.

jdbc драйвер вставки с nested поддерживает? что-то не найду

думаю их можно вставить как массивы как в примере с Netsted здесь https://clickhouse.yandex/docs/en/query_language/queries.html#array-join-clause одномерные массивы поддерживаются в jdbc.

кажется нашел INSERT INTO nested_test VALUES ('Hello', [1,2], [10,20]), ('World', [3,4,5], [30,40,50]),

спсб Сергей

при изменении background_pool_size значения нужно перезапускать сервер? или настройка установится на лету?

точнее она установилась судя по выборке из system.settings, но вот вступила ли в силу не понятно

при изменении background_pool_size значения нужно перезапускать сервер? или настройка установится на лету?

Нужно. Это одна из настроек, которая имеет эффект только при старте сервера.

ясно. а по ZNODEEXISTS случаем не возникло идей что делать? у нас эта ошибка продолжает сыпатся :(

Нужно. Это одна из настроек, которая имеет эффект только при старте сервера.

а где можно посмотреть для каких настроек нужно делать рестарт?