Ага, тогда вроде похоже

Если вертикальный мерж, то сначала мержится первичный ключ, а затем остальные столбцы по очереди.

А когда следует применять вертикальный мёрж?

Он включается автоматически при некоторой эвристике на размер куска.

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

Т.е. если памяти хватает, то не имеет смысла форсировать какими-то настройками его активацию?

В логе должен быть stacktrace ниже. Можете показать?

0. clickhouse-server(StackTrace::StackTrace()+0x15) [0x82e3db5] 1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x21) [0x2cc1371] 2. clickhouse-server(DB::throwReadAfterEOF()+0x4c) [0x2cc13dc] 3. clickhouse-server(DB::readVarUInt(unsigned long&, DB::ReadBuffer&)+0x1f9) [0x2cd2de9] 4. clickhouse-server(DB::TCPHandler::isQueryCancelled()+0x149) [0x2ccd139] 5. clickhouse-server(DB::TCPHandler::processOrdinaryQuery()+0x2fe) [0x2ccddae] 6. clickhouse-server(DB::TCPHandler::runImpl()+0x547) [0x2cd12e7] 7. clickhouse-server(DB::TCPHandler::run()+0x2a) [0x2cd1f2a] 8. clickhouse-server(Poco::Net::TCPServerConnection::start()+0xe) [0x85caf8e] 9. clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x169) [0x85cb369] 10. clickhouse-server(Poco::PooledThread::run()+0x76) [0x8be1c86] 11. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0x37) [0x8bdde97]

Т.е. если памяти хватает, то не имеет смысла форсировать какими-то настройками его активацию?

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

Есть пара настроек в merge_tree_settings - vertical_merge_algorithm_min_rows_to_activate и vertical_merge_algorithm_min_columns_to_activate. Можно попробовать с ними поиграться. В логе написано, какой вариант мержа выбран: Selected MergeAlgorithm: Vertical либо Selected MergeAlgorithm: Horizontal

Есть пара настроек в merge_tree_settings - vertical_merge_algorithm_min_rows_to_activate и vertical_merge_algorithm_min_columns_to_activate. Можно попробовать с ними поиграться. В логе написано, какой вариант мержа выбран: Selected MergeAlgorithm: Vertical либо Selected MergeAlgorithm: Horizontal

Меня скорее не память беспокоит, а время мёржей. Хотел понять, не станет ли вертикальный мёрж серебряной пулей, которая ускорит процесс

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

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

0. clickhouse-server(StackTrace::StackTrace()+0x15) [0x82e3db5] 1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x21) [0x2cc1371] 2. clickhouse-server(DB::throwReadAfterEOF()+0x4c) [0x2cc13dc] 3. clickhouse-server(DB::readVarUInt(unsigned long&, DB::ReadBuffer&)+0x1f9) [0x2cd2de9] 4. clickhouse-server(DB::TCPHandler::isQueryCancelled()+0x149) [0x2ccd139] 5. clickhouse-server(DB::TCPHandler::processOrdinaryQuery()+0x2fe) [0x2ccddae] 6. clickhouse-server(DB::TCPHandler::runImpl()+0x547) [0x2cd12e7] 7. clickhouse-server(DB::TCPHandler::run()+0x2a) [0x2cd1f2a] 8. clickhouse-server(Poco::Net::TCPServerConnection::start()+0xe) [0x85caf8e] 9. clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x169) [0x85cb369] 10. clickhouse-server(Poco::PooledThread::run()+0x76) [0x8be1c86] 11. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0x37) [0x8bdde97]

Выглядит так, будто связь с нодой обрывается. Есть ли что-нибудь в логах самой ноды?

Выглядит так, будто связь с нодой обрывается. Есть ли что-нибудь в логах самой ноды?

на ней появляется такое HTTPHandler: Code: 279, e.displayText() = DB::NetException: All connection tries failed

Выглядит так, будто связь с нодой обрывается. Есть ли что-нибудь в логах самой ноды?

с таким стек трейсом 0. clickhouse-server(StackTrace::StackTrace()+0x15) [0x82e3db5] 1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x21) [0x2cc1371] 2. clickhouse-server(PoolWithFailoverBase<DB::IConnectionPool>::getMany(unsigned long, unsigned long, std::function<PoolWithFailoverBase<DB::IConnectionPool>::TryResult (DB::IConnectionPool&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)> const&, std::function<unsigned long (unsigned long)> const&, bool)+0x1805) [0x7f39355] 3. clickhouse-server(DB::ConnectionPoolWithFailover::getManyImpl(DB::Settings const*, DB::PoolMode, std::function<PoolWithFailoverBase<DB::IConnectionPool>::TryResult (DB::IConnectionPool&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)> const&)+0xcc) [0x7f313fc] 4. clickhouse-server(DB::ConnectionPoolWithFailover::getManyChecked(DB::Settings const*, DB::PoolMode, DB::QualifiedTableName const&)+0x8d) [0x7f318bd] 5. clickhouse-server() [0x75e4797] 6. clickhouse-server(DB::RemoteBlockInputStream::sendQuery()+0x41) [0x75e6cd1] 7. clickhouse-server(DB::IProfilingBlockInputStream::readPrefix()+0x58) [0x75cf128] 8. clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::Handler, (DB::StreamUnionMode)0>::thread(MemoryTracker*, unsigned long)+0x175) [0x7cf82f5] 9. clickhouse-server() [0x8d9675e] 10. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76b9) [0x7f6f419736b9] 11. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6c) [0x7f6f413a041c]

на ней появляется такое HTTPHandler: Code: 279, e.displayText() = DB::NetException: All connection tries failed

Должно быть, в этот момент пропало соединение меджу нодами. Не знаю, как это можно подтвердить.

@kochetovnicolai , Сейчас в htop вот такая ситуация PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 26088 clickhous 20 0 531G 112G 33184 S 307. 89.0 18h40:48 clickhouse-server --daemon --pid-file=/var/run/clickhouse-server/clickhouse-server.pid --config-file=/etc/clickhouse-server/config.xml Веб-интерфейс и клиент залипли. Вроде бы должен был идти мердж Как прояснить ситуацию?

в perf top что-нибудь видно?

25,80% [kernel] [k] isolate_freepages_block 18,06% clickhouse [.] SpinLock::SlowLock 12,13% [kernel] [k] rcu_irq_exit

в perf top что-нибудь видно?

периодически spinlock и isolate меняются местами

18,93% clickhouse [.] SpinLock::SlowLock 14,38% [kernel] [k] isolate_freepages_block 9,31% [kernel] [k] timerqueue_add

есть предположение, что isolate_freepages_block из-за нехватки памяти

может быть там какой-нибудь запрос съедает все ресурсы?

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

Но был мерж на 100 Гб

сейчас он завершился?

Можно и так сказать - клик упал

всмысле, упал во время предыдущего мержа? тогда мерж мог назначиться опять

Я не мог посмотреть т.к ни один интерфейс не отвечал нормально

логи тоже нельзя посмотреть?

Можно, конечно

2018.05.14 15:19:58.069953 [ 452 ] <Error> executeQuery: Code: 252, e.displayText() = DB::Exception: Too many parts (310). Merges are processing significantly slower than inserts., e.what() = DB::Exception (from 10.55.1.50:57146) (in que

А последними его словами были 2018.05.14 15:20:02.848559 [ 668 ] <Error> SystemLog (system.query_log): SystemLog queue is full

Yj nfrjuj gjkyj d kjut

Но такого полно в логе

в таблице merges есть столбец про память, он нормально отображает сколько памяти мерж ест. select (memory_usage/1024/1024/1024) m,* from system.merges order by m desc

И проблема воспроизводится даже с отключенным логированием

в таблице merges есть столбец про память, он нормально отображает сколько памяти мерж ест. select (memory_usage/1024/1024/1024) m,* from system.merges order by m desc

Когда у меня была возможность следить за ним, там было вменяемое число

2018.05.14 15:19:58.069953 [ 452 ] <Error> executeQuery: Code: 252, e.displayText() = DB::Exception: Too many parts (310). Merges are processing significantly slower than inserts., e.what() = DB::Exception (from 10.55.1.50:57146) (in que

ну вот, мержи не успевают проходить :( вставки не слишком частые? свободное место на диске есть?

Место есть

добрый день, а какие могут быть причины у КХ после рестарта не слушать порт? судя по логам, он активно тащит партиции с других реплик

Вставки да, есть частые, но обычно успевает

ну вот, мержи не успевают проходить :( вставки не слишком частые? свободное место на диске есть?

Я посмотрел, жирного мержа в merges уже нет

бОльшую часть данных стараемся вставлять через buffer

У меня есть ощущение, что что-то не так.. НА момент падения базы в tmp_merges было почти полсотни гигабайт.

Вряд ли они оперативно домержились, и при этом новый большой мерж не создался

да, многовато для куска на 100GB. не вышло так, что мерж съел все место?

неа

Контроллирую

добрый день, а какие могут быть причины у КХ после рестарта не слушать порт? судя по логам, он активно тащит партиции с других реплик

что в логах? что сервер при старте в stdout сказал?

Include not found: clickhouse_remote_servers Include not found: clickhouse_compression Include not found: networks message repeated 3 times: [ Include not found: networks] Couldn't save preprocessed config to /etc/clickhouse-server/config-preprocessed.xml: Access to file denied: /etc/clickhouse-server/config-preprocessed.xml Logging trace to /var/log/clickhouse-server/clickhouse-server.log Logging errors to /var/log/clickhouse-server/clickhouse-server.err.log Include not found: networks message repeated 3 times: [ Include not found: networks] Couldn't save preprocessed config to /etc/clickhouse-server/users-preprocessed.xml: Access to file denied: /etc/clickhouse-server/users-preprocessed.xml

в логах много ZooKeeperImpl::Exception: Session expired (Session expired) но началось сильно давно

пока больше ничего выдающегося не выловил

похоже что загружает базы и таблицы и до слушания портов еще дело не дошло

а zookeeper жив? версия clickhouse какая?

да, многовато для куска на 100GB. не вышло так, что мерж съел все место?

Мерж начался заново

жив, соседняя реплика рестарт переживает, версия 1.1.54343

Как подстраховаться? Может, какие-то метрики подмониторить до момента, пока интерфейсы не залипнут ?

сервер еще не запустился и не начала принимать запросы - обычные метрики снять нельзя

можно попроьовать снять трейс gdb - sudo gdb -p $(pidof -s clickhouse-server) -batch -ex 'set pagination off' -ex 'thread apply all backtrace' -ex 'detach' -ex 'quit' > trace.log

Какова в КХ логика потребления памяти? https://i.gyazo.com/0b263bf3839a312041ac4c9a503714d0.png

Почему мелки запросы хотят по 3 Гб, а мерж на 100 Гб - 18 Мб?

Подскажите, пожалуйста, как в ClickHouse отфильтровать данные по полю srcaddr (ipv4), входящие в сеть, например, 10.1.1.192/27? А не входящие в сеть?

Какой тип хранения данных для этой задачи оптимальный?

Подскажите, пожалуйста, как в ClickHouse отфильтровать данные по полю srcaddr (ipv4), входящие в сеть, например, 10.1.1.192/27? А не входящие в сеть?

https://clickhouse.yandex/docs/en/single/#functions-for-working-with-ip-addresses

Большое спасибо!

@kochetovnicolai Вот прямо сейчас проблема наблюдается: залипли все интерфейсы, растет потребление памяти, свободное место имеется

в iotop ничего страшного

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

Такое ощущение, что часть тредов ещё худо-бедно работает

сейчас топ выглядит так: 18,17% clickhouse [.] SpinLock::SlowLock 18,15% clickhouse [.] tcmalloc::PageHeap::AllocLarge 12,16% [kernel] [k] deactivate_task 9,91% clickhouse [.] LZ4_decompress_fast 9,31% clickhouse [.] std::_Rb_tree_insert_and_rebalance

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

А как быть во втором случае? ПРосто удалить 100 Гб данных ?

Сегодня потратил пару часов на кейс с PREWHERE vs WHERE и optimize_move_to_prewhere. Обычно оптимизатор при небольших условиях и большом количестве колонок благополучно перебрасывает условия из WHERE в PREWHERE. Сегодня наткнулся на кейс: если колонка по которой выполняется WHERE входит в PK (даже если на самом конце PK) то оптимизатор оставляет её в WHERE чем может сильно замедлять селект. Думаю вот теперь - это баг или фичер :) Тут пример: https://gist.github.com/filimonov/dd62b964cf3692ef272f3bc479ef50fe

А как быть во втором случае? ПРосто удалить 100 Гб данных ?

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

При этом вот этот большой мерж использует 19638304 памяти

Сегодня потратил пару часов на кейс с PREWHERE vs WHERE и optimize_move_to_prewhere. Обычно оптимизатор при небольших условиях и большом количестве колонок благополучно перебрасывает условия из WHERE в PREWHERE. Сегодня наткнулся на кейс: если колонка по которой выполняется WHERE входит в PK (даже если на самом конце PK) то оптимизатор оставляет её в WHERE чем может сильно замедлять селект. Думаю вот теперь - это баг или фичер :) Тут пример: https://gist.github.com/filimonov/dd62b964cf3692ef272f3bc479ef50fe

Пока оптимизатор не опирается на статистику по данным - это скорее фича

При этом вот этот большой мерж использует 19638304 памяти

Это можно объяснить тем, что первичный ключ мог успеть помержиться. Или тем, что мало столбцов. Мержи не зачитывают в памть все данные.

Это можно объяснить тем, что первичный ключ мог успеть помержиться. Или тем, что мало столбцов. Мержи не зачитывают в памть все данные.

А какие ручки можно покрутить, заставляя КХ мержить меньшими кусками?

max_bytes_to_merge_at_max_space_in_pool - максимальный возможный размер куска эту настройку можно изменить в секции merge_tree_settings по умолчанию она 150 * 1024 * 1024 * 1024

Это не повлияет на уже смерженные куски ?

нет

А можно как-нибудь, теоретически, повлиять на скорость мержа? Ну там приоритет поднять или ещё как ?

А можно как-нибудь, теоретически, повлиять на скорость мержа? Ну там приоритет поднять или ещё как ?

Я такого способа не знаю. Думаю, что его сейчас нет.

Я такого способа не знаю. Думаю, что его сейчас нет.

спасибо

господа, подскажите по odbc драйверу, он читает типы и int и datetime и date, но не читает string

что значит не читает? какой запрос и откуда сделан?

что значит не читает? какой запрос и откуда сделан?

есть сервер MSSQL у него линк в сторону Clickhouse через ODBC, я делаю запрос из MSSQL, если делают SELECT с полем типа даты или инт - запрос отрабатыват, если же string - ошибка

Есть ли ограничения на использование сильно денормализованных данных, когда на одну и ту же дату/время приходится множество одинаковых/мало отличающихся записей?

Есть ли ограничения на использование сильно денормализованных данных, когда на одну и ту же дату/время приходится множество одинаковых/мало отличающихся записей?

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

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

Спасибо

Единственное ограничение которое в голову приходит - если вы сделаете 2 _абсолютно_ идентичных инсерта (количество сктрок и все значения будут совпадать) в реплицируемую таблицу, то второй инсерт будет отброшен как дубликат.

yandex/ClickHouse was tagged: v1.1.54381-stable Link: https://github.com/yandex/ClickHouse/releases/tag/v1.1.54381-stable Release notes: v1.1.54381-stable

Ребят, а в новой версии пофикшена регрессия с подзапросами?

Что бы понятно было о чем идет речь

Есть регрессия производительности при анализе запросов с большим количеством подзапросов в FROM. Я имел её ввиду ещё когда готовил релиз, но решил что это пока не очень важно, так как она начинает иметь значение на цепочках из хотя бы десятков подзапросов. Исправить можно.

привет. подскажите пожалуйста, в дефолтном конфиге <macros incl="macros" optional="true" /> значит ли это, что если я создам в /etc/clickhouse-server/macros.xml, то он подключится?

Нет