-c IP -R

ubuntu@pprod-spm-ch-3:~$ iperf -c 10.1.1.86 -R —---------------------------------------------------------- Client connecting to 10.1.1.86, TCP port 5001 TCP window size: 325 KByte (default) —---------------------------------------------------------- [ 3] local 10.1.1.251 port 46066 connected with 10.1.1.86 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 5.82 GBytes 4.99 Gbits/sec

-c ip -d

Vladimir о, еще глупый вопрос - у тебя хостнеймы указаны в КХ же, да?

попробуй по хостнейму клиентом iperf'а

мало ли что

не, у меня там ip

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

^Cubuntu@pprod-spm-ch-3:~$ iperf -c 10.1.1.86 -d —---------------------------------------------------------- Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) —---------------------------------------------------------- —---------------------------------------------------------- Client connecting to 10.1.1.86, TCP port 5001 TCP window size: 1.17 MByte (default) —---------------------------------------------------------- [ 5] local 10.1.1.251 port 47844 connected with 10.1.1.86 port 5001 [ 4] local 10.1.1.251 port 5001 connected with 10.1.1.86 port 44896 [ ID] Interval Transfer Bandwidth [ 5] 0.0-10.0 sec 5.81 GBytes 4.99 Gbits/sec [ 4] 0.0-10.0 sec 5.81 GBytes 4.99 Gbits/sec

а что ради интереса - до ZK все также ок?

5 мин отойду , невтерпеж :D

ZK на тех же 3 машинах это может не суперправильно но это тест у меня. ZK пишет в другой диск тоже SSD

сделал батчи по 1.5M

стало писать по 25-30 раз в минуту

-26 inserts/min -25 inserts/min

Вот это необяснимо, да? ubuntu@pprod-spm-ch-3:~$ for i in seq 1 5; do curl 'pprod-spm-ch-3:8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 156501169 156501169 227514652 152327963 223507989

Вот это необяснимо, да? ubuntu@pprod-spm-ch-3:~$ for i in seq 1 5; do curl 'pprod-spm-ch-3:8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 156501169 156501169 227514652 152327963 223507989

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

и количество кусков у тебя необъяснимо

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

у меня на этой цифре зависло

SELECT count(*) FROM system.parts AS active ┌─count()─┐ │ 7982 │ └─────────┘

и никуда не двигается

из разного набора реплик да, но они должны сходится

Можно я выложу как создавал и конфиги свои? может заметно будет где ошибка?

Это что значит? 2017.08.02 13:38:46.570499 [ 6589 ] <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/measures/02/replicas/2, e.what() = DB::Exception, Stack trace: 2017.08.02 13:38:46.592134 [ 83 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace: 2017.08.02 13:38:46.592190 [ 102 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace: 2017.08.02 13:38:46.610775 [ 125 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace: 2017.08.02 13:38:46.618404 [ 6589 ] <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/measures/01/replicas/2, e.what() = DB::Exception, Stack trace: 2017.08.02 13:38:46.626119 [ 6583 ] <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/measures/02/replicas/2, e.what() = DB::Exception, Stack trace:

replica 2 недоступна?

В ZK вроде есть такой путь [zk: localhost:2181(CONNECTED) 8] ls /clickhouse/tables/measures/02/replicas/2 [is_active, columns, max_processed_insert_time, host, parts, flags, log_pointer, min_unprocessed_insert_time, queue]

Я бы попробовал собрать кластер без шардов, только реплики. А только потом сделать Disturbed

Причем на части данных, для скорости

тоесть 1 шарду в remote server указать и 2 реплики для нее? писать в любую 1 локальную таблицу?

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

И разбираться с распределенными запросами

Имеет смысл Не думал что столько глаблей сразу встречу просто.

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

Просто 2 реплики синхронизируются быстро

ubuntu@pprod-spm-ch-3:~$ for i in seq 3 4; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 67500250 67500250 ubuntu@pprod-spm-ch-3:~$ ubuntu@pprod-spm-ch-3:~$ for i in seq 3 4; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 142048934 142048934 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 4; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 142488667 142490947 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 4; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 142500364 142500364 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 4; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 142500364 142500364

сейчас верну распределенность

Интересно что количество parts не растет и все успевает мержиться

сейчас верну распределенность

Попробуйте залить все данные. Может проблема появиться после некого объема данных

давай на ты пожалуйста

ок

сделаю как ты сказал

Вставилось около 300М строк и все было ок. Кол-во parts не превышало 100 мержить успевало

Переделал на Distributed и с первых секунд начались проблемы

Вот создание таблиц

Вот remote_servers.xml

Где-то тут ошибка

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

Где-то тут ошибка

Сложно сказать, я пока не пробовал реплицировать и шардировать на CH. В твоей схеме три шарда, сделай два

Как минимум, почему тут http://joxi.ru/RmzNOePtWVpO8m пусто? Вот что в доке http://joxi.ru/gmvzZ3Pix05Z5m

там выше говориличто если тут пусто то берет БД из remote servers

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

https://github.com/yandex/ClickHouse/blob/master/dbms/tests/integration/test_cross_replication/test.py

А вставляешь ты в распределенную таблицу или приложением в каждый шард?

в распределенную

ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+shard_1.measures;'; done; 29669439 61325190

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

Я бы даже сказал не отстает а в 2 раза больше результаты показывает одна из реплик

ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+shard_1.measures;'; done; 40169007 81393576

Vladimir ты шлешь напрямую в сервера или в распределенную таблицу?

в распределенную

ERROR: S client not available

еще я вижу много такого в логах но что это и почему не понятно 2017.08.02 15:18:58.384768 [ 4262 ] <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/02/measures/replicas/2, e.what() = DB::Exception, Stack trace: 2017.08.02 15:18:58.396931 [ 39 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace: 2017.08.02 15:18:58.519827 [ 4270 ] <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/02/measures/replicas/2, e.what() = DB::Exception, Stack trace: 2017.08.02 15:18:58.535047 [ 102 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace: 2017.08.02 15:18:58.542597 [ 4262 ] <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/02/measures/replicas/2, e.what() = DB::Exception, Stack trace: 2017.08.02 15:18:58.553679 [ 49 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace:

Сделал кластер без реплик, теперь распределенная таблица возвращает синхрнизированние данные

ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 69892767 70000700 70000700 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 70500703 70500703 70500703 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 71491774 71495408 71496055

Что мы имеем: 1. Реплицированная таблица работает и реплики не отстают друг от друга. Проблем с мержем нету system.parts всегда маленькое. 2. Распределенная таблицв работает, все 3 распределенные таблицы (на разных серверах) поверх одних и тех же Merge таблиц возвращают одинаковые данные. Появляется проблема с system.parts. Через 10 мин работы видно такое SELECT count(*) FROM system.parts ┌─count()─┐ │ 6150 │ └─────────┘ 1 rows in set. Elapsed: 0.021 sec. Processed 6.15 thousand rows, 1.21 MB (290.54 thousand rows/s., 57.03 MB/s.) 3. Распределенная таблица поверх реплицированных как по схеме тут (шарды а разных БД чтобы можно было создать таблицы с одинаковыми именами) https://github.com/yandex/ClickHouse/blob/master/dbms/tests/integration/test_cross_replication/test.py не работает. Есть и проблема с system.parts как в пункте 2, так и данные вазвращаются несогласованные от каждой распределенной таблицы ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 197847333 209820192 257339801 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 257339801 257339801 205673865 Алексей может у Вас есть идеи что в моих руках и голове не так?.

можно в корне clickhouse сделать директорию private, положить туда свои исходники и CMakeLists.txt и оно автоматически подхватится

Привет! А можешь поподробнее рассказать про подкладывание в private? Туда можно положить как-то чтобы оно само в libdbms.a дописалось или нужно другой lib*.a делать?

С распределенной таблицей начались проблемы с мержем, кто угадает время по картинке?

А вот еще интересная статистика system.events показывает │ InsertedRows │ 4711779888 │ А таблицы показывают ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 3190003655 3190003947 3190004375 Вставку я прекратил 3 мин назад а кол-во строк растет

Где-то очередь на полтора миллиарда строк?

Через 2 мин стабилизировалось на такой цифре ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 3286834653 3286834653 3286834653

Почему не бъется с InsertedRows и почему вообще после прекращения вставки количество строк росло 2 мин непонятно. Неужели так забуфферизировало. Я тут всех запарил чувствую, простите, ответов так и не понаходил

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

спсб за поддержку, ушел на перекур (не курю :) )

А ты не пробовал через буфер с num_layers=1 ?

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

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

Я чаще чем раз в секунду вставляю и все норм. 6-7 миллионов строк в минуту получается

Лью в 100 потоков

>Я чаще чем раз в секунду вставляю и все норм. 6-7 миллионов строк в минуту получается Я тоже чаще в вставлял и вопросов не было. Все началось при репликации + шардирование

>А ты не пробовал через буфер с num_layers=1 ? не пробовал. тут вопрос не в том как сделать, а почему оно не мержит само интенсивно когда проессоры простаивают

Ну и чехарда с count() при репликации и шардировании, и увеличение кол-ва строк после того как инсерты застопились 2 мин назад. Много непонятного какого-то

Я вот сейчас до перекура поставил пачки по 3млн и ушел. Стабилизировалось все на таких цифрах ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+system.parts;'; done; 5701 4866 4734

Меня устраивает впринципе, гдавное что стабилизировалось и перестало отдавать ошибки

Неохота делать 2*2 на 4 серверах. Не могу никак понть почему 3*2 на 3 не работает. 2*2 и серверов больше и читать только с 2 в одном запросе, минусы одни

Кажется что всё проблемы от вставки через Distributed-таблицу. Насколько я помню, кто-то писал что в Яндекс.Метрике используют вставку напрямую в локальные таблицы. И вставка через Distributed не рекомендуется.

А как это согласуется с тем что если Distrinuted поверх нереплицированных таблиц то все более менее ок?

Всем привет, в документации сказано "We do not recommend storing floating-point numbers in tables.", а какие есть альтернативы?

Всем привет, в документации сказано "We do not recommend storing floating-point numbers in tables.", а какие есть альтернативы?

integer

а как быть не целой частью числа?

хранить в отдельных колонках?)

Умножать же. Если 2 знака после запятой - на 100.