напишу тогда в гугл.группы, чтобы тут не флудить

напишу тогда в гугл.группы, чтобы тут не флудить

Тут где то выше говорили про ограничения памяти для фонового слияния. Мб оно

нашел тут такой совет: threshold for maximum total size of merged parts, by default - 100 GB. In config.xml, write <merge_tree> <max_bytes_to_merge_at_max_space_in_pool>100000000000</max_bytes_to_merge_at_max_space_in_pool> </merge_tree> with desired value.

поможет ли это интересно

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

делаю ALTER TABLE $TABLE FREEZE PARTITION '2'

он в shadow кладет все данные таблицы. потом эти данные копирую архивирую и загружаю на бэкап сервер

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

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

Кажется что после слияния размер может стать меньше.

на 1 gb ?

бывало и на 3 gb

Конечно, после мержа оч сильно жмутся данные

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

По поводу Couldn't remove 20170628_20170628_230133_230133_0 from ZooKeeper: no node Новая версия 1.1.54242 считает это как exception и добавляет к ZooKeeperExceptions в system.events. Это баг или фича? А то я эту цифру мониторю, потому что у меня реальные exception случаются, которые только перезагрузкой можно починить.

Конечно, после мержа оч сильно жмутся данные

значит бояться нечего. бэкапы полные. спасибо

значит бояться нечего. бэкапы полные. спасибо

Ну все же справедливости ради важно помнить что рабочим бекап становится только после успешного восстановления )

Где-то в документации написано, что для ускорения вставки данных, можно вставлять в несколько потоков. Насколько много потоков можно использовать?

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

все очень индивидуально

зависит и от железа и от вашего решения

Processed ..., 16Gb - это расход памяти используемой при запросе или количество данных обработанных?

Code: 1000. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Access to file denied: insufficient permissions: /var/lib/clickhouse/data/Ermolenko/MIGRATES/20170602_20170602_2_2_0/FILENAME.bin. Error: Process 13726 detected, but you don't have permission to control it

от чего может возникать эта ошибка?

drwxr-xr-x 7 clickhouse clickhouse 4096 Jun 14 15:19 Ermolenko

Processed ..., 16Gb - это расход памяти используемой при запросе или количество данных обработанных?

Это количество прочитанных на сколько я помню

drwxr-xr-x 7 clickhouse clickhouse 4096 Jun 14 15:19 Ermolenko

Ну прав не хватает, очевидно же

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

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

max_usage?

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

Возможно много интересно увидишь в system.query_log

Где-то в документации написано, что для ускорения вставки данных, можно вставлять в несколько потоков. Насколько много потоков можно использовать?

При вставке в одну и туже таблицу при увеличении числа пишущих потоков скорость только упадет. Кликхаус достаточно шустро пишет, нужно смотреть во что вы упираетесь

В том то и дело, я не упираюсь. Потому и возник вопрос, стоит ли писать в несколько потоков, ведь это не может быть "бесплатным". Спасибо за пояснение

В том то и дело, я не упираюсь. Потому и возник вопрос, стоит ли писать в несколько потоков, ведь это не может быть "бесплатным". Спасибо за пояснение

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

Тут же все сильно индивидуально. Кто-то на рейдах из SSD работает, а кто-то на полуживых 7200rpm

Возможно много интересно увидишь в system.query_log

Понял. Спасибо. Но в клиенте сразу видеть всё равно было бы удобно :)

Понял. Спасибо. Но в клиенте сразу видеть всё равно было бы удобно :)

Согласен ))

/stat@combot

combot.org/chat/-1001080295593

Тут же все сильно индивидуально. Кто-то на рейдах из SSD работает, а кто-то на полуживых 7200rpm

Как-то такой подход мне не нравится. Это ж "исчо адын индекс". Ресурсов не хватило потестировать и выяснить правила для подбора оптимального числа потоков?

Как-то такой подход мне не нравится. Это ж "исчо адын индекс". Ресурсов не хватило потестировать и выяснить правила для подбора оптимального числа потоков?

Ну я ж говорю, кто-то работает на 40ядерных двухпроцессорных железных машинах, а у кого то вся инфраструктура на виртуалках Амазона. Кто то пишет терабайты в день, а у кого то терабайт и за месяц не наберется. Таблицы разные бывают, как по движкам так и по количеству колонок и типам данных в них. Все сильно индивидуально.

Добрый день, скажите если добавить пользователя ubuntu в группу clickhouse - не будет ли проблем с доступом ?

Добрый день, скажите если добавить пользователя ubuntu в группу clickhouse - не будет ли проблем с доступом ?

А какая задача решается?

А какая задача решается?

когда импорт данные делаю - на файлах владелец ubuntu и потом конфликт доступа происходит при запросах

Тогда тут надо пользователя ClickHouse в группу Ubuntu, нет?

когда импорт данные делаю - на файлах владелец ubuntu и потом конфликт доступа происходит при запросах

а как импорт делаешь? Руками файлы чтоль подсовываешь?

а как импорт делаешь? Руками файлы чтоль подсовываешь?

выгружаю партиции в shadow. потом их копирую в папку - архивирую папку и в облако

с облака беру бэкап. распаковываю в data данные удаляю. свои загружаю. сервер запускаю

выгружаю партиции в shadow. потом их копирую в папку - архивирую папку и в облако

так, и на каком из этапов проявляется ошибка

с облака беру бэкап. распаковываю в data данные удаляю. свои загружаю. сервер запускаю

просто надо сменить овнера у тех файлов которые подложил

команда chown

да я знаю)

но она не меняет всем файлам владелца

у нее есть флаг -R

не работает

приходится делать так

sudo find data -type f -exec chown clickhouse:clickhouse {} \;

но это слишком долго по времени

chown clickhouse:clickhouse ./имя директории с проблемными файлами -R

Либо просто лейте файлы под юзером clickhouse

Либо просто лейте файлы под юзером clickhouse

а как от другого пользователя выполнить ?

sudo -u clickhouse %command_name%

как вариант сча попробую

сколько ж у вас там файлов что chown отрабатывает долго

Всем привет! У нас критическая проблема с кластером на КХ! Я писал об этом в группу, мерж между нодами отваливается, данные не нормализуются, скачат все время, очень много ошибок типа Too much parts. Merges are processing significantly slower than inserts и statistics_523.track_sharded (Merger): Part 20170606_20170611_545228_1109144_1560 intersects previous part 20170601_20170606_200_565402_2676 Вставляем балком по 100-500 записей в секунду но с разных источников. На каждой ноде больше терабайта данных, 6 нод, 3 шарда по 2 реплики. Как можно победить эти ошибки? Кто может сталкивался с таким?

Всем привет! У нас критическая проблема с кластером на КХ! Я писал об этом в группу, мерж между нодами отваливается, данные не нормализуются, скачат все время, очень много ошибок типа Too much parts. Merges are processing significantly slower than inserts и statistics_523.track_sharded (Merger): Part 20170606_20170611_545228_1109144_1560 intersects previous part 20170601_20170606_200_565402_2676 Вставляем балком по 100-500 записей в секунду но с разных источников. На каждой ноде больше терабайта данных, 6 нод, 3 шарда по 2 реплики. Как можно победить эти ошибки? Кто может сталкивался с таким?

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

У нас такое периодически бывает. Помогает рестарт клика, с которго идут ошибки. Он потом догоняет

"по 100-500 записей в секунду но с разных источников" а сколько источников таких?

штук 30

ну т.е. идет 30 инсертов в секунду?

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

Сейчас попробуем увеличить время буферизации.

А лучше пишите куда-нибудь вроде kafka/nats.io и от туда выгребайте и пишите пачками с 1-го "источника" в КХ

сколько ж у вас там файлов что chown отрабатывает долго

18 гигов данных

сколько ж у вас там файлов что chown отрабатывает долго

chown почему-то не проставляет владельца на файлы

даже с -r флагом

-R флаг

А лучше пишите куда-нибудь вроде kafka/nats.io и от туда выгребайте и пишите пачками с 1-го "источника" в КХ

Да, это просто еще не до конца реализовано.

даже с -r флагом

-R большая. Обозначает рекурсивное проставление. Т.е. по всем поддиректориям указанной директории.

18 гигов данных

Объём не важен, важно количество файлов

-R большая. Обозначает рекурсивное проставление. Т.е. по всем поддиректориям указанной директории.

не работает. не знаю почему. проще наверное сделать mv из shadow от clickhouse owner

там еще детали обработки симлинков есть, если у вас есть они

и tar тоже

не работает. не знаю почему. проще наверное сделать mv из shadow от clickhouse owner

rsync -a