Successful import -> restart server -> Connection refused

[Юрий Кудряшов]

Приветствую.

Сделал импорт большого массива.
Все успешно вошло.

создалось порядка ~190 000 parts (соот-но папок в папке с таблицей).
Необходимо было перезагрузить калькулятор (кликхаус корректно остановился и ушел в ребут).

$ clickhouse-client
ClickHouse client version 1.1.54002.
Connecting to localhost:9000.
Code: 210. DB::NetException: Connection refused: (localhost:9000, 127.0.0.1)

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

[Юрий Кудряшов]

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

среда, 7 сентября 2016 г., 17:24:54 UTC+3 пользователь Юрий Кудряшов написал:

[man...@gmail.com]

Привет. При нормальной работе сервера, не должно возникать ситуации со столь большим количеством parts.
Количество parts должно поддерживаться в районе 1..200 для каждого месяца.

При столь большом количестве parts, всё будет работать очень плохо.
Соответственно, мне нужно больше деталей, чтобы понять, почему в вашем случае это происходит.
Будет хорошо, если вы сможете привести определение таблицы; информацию о том, как загружаются данные; и какое либо описание конфигурации вашего сервера.

[Юрий Кудряшов]

структура:

CREATE TABLE IF NOT EXISTS db.table
(
    f1 Int64,
    f2  Int64,
    f3  Int64,
    f4  Int64,
    createdDay DEFAULT toDate(date),
    date DateTime,
    f5 String,
    f6  Int64,
    f7  Int64,
    f8  Int64,
    z1 Nested
    (
      ID UInt64,
      Type String
    )

) ENGINE = MergeTree(createdDay, (f1,f2, createdDay), 8192)

Импорт идет так:

clickhouse-client --query='INSERT INTO ...' < BIGFILE.tsv

BIGFILE.tsv - это файл размером в ~300 Gb (c 2.8 млрд строк)

Вставка идет чуть больше часа на таком калькуляторе:
asus m5a97 rel 2.0
AMD FX(tm)-8320 Eight-Core Processor × 8
16 gb

Потом где-то часов 12 уменьшает количество parts до 131.

четверг, 8 сентября 2016 г., 15:58:06 UTC+3 пользователь man...@gmail.com написал:

[man...@gmail.com]

Клиент вставляет данные некоторыми блоками, по-умолчанию - 1 048 576 строк.
При вставке, сервер разбивает блоки по партициям - месяцам, и для каждого формирует кусок (part) - директорию в файловой системе.
Если в дампе данные для разных месяцев идут в перемешку, то сервер может формировать много кусков.

Сервер постоянно производит фоновые слияния. Для слияния выбирается некоторое количество кусков в одной партиции и формируется кусок большего размера.
После слияния, исходные (старые) куски удаляются не сразу, а через (по-умолчанию) 8 минут и только тогда, когда ни один SELECT их не использует.
Куски, оставшиеся после слияния, называются неактивными. Такие куски используются для более простого восстановления после сбоя.

Посмотреть набор кусков можно запросом SELECT * FROM system.parts. Только активных: SELECT * FROM system.parts WHERE active.
В следующих SELECT запросах используются только активные куски.

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

Почему в вашем случае возникает много кусков, навскидку сказать не могу.

[Evgeni Makarov]

сегодня в процессе тестирования (разбираюсь с Clickhouse первую неделю в фоновом режиме) имел такую же ошибку два раза

пока сбрасываю на то, что работаю через Parallels на ноутбуке и не хватает каких то ресурсов

табличка простая - порядка 8 колонок

идет запись с частотой примерно 20 строк в секунду (использую проект ORM для python https://github.com/Infinidat/infi.clickhouse_orm)

вторник, 13 сентября 2016 г., 22:23:51 UTC+3 пользователь man...@gmail.com написал:

[Evgeni Makarov]

в моем случае, просто появлялась ошибка и сервер clickhouse переставал отвечать с ошибкой

Code: 210. DB::NetException: Connection refused: (localhost:9000, 127.0.0.1)

не очень приятный момент, надо сказать. в какую сторону копать?

четверг, 8 декабря 2016 г., 18:01:39 UTC+3 пользователь Evgeni Makarov написал:

[man...@gmail.com]

Для начала проверьте, хватает ли оперативной памяти на машине.
Например, для загрузки тестовых данных из tutorial, требуется по крайней мере 8 GB.
Посмотреть можно, набрав dmesg после недоступности сервера, и изучив сообщения, которые там расположены,
либо наблюдая вживую за потреблением оперативки в top-е, либо смотря графики оперативки, если такие есть.

Далее. Если ClickHouse не самой свежей версии, то установите последнюю.

Посмотреть, какая версия последняя, можно здесь: http://repo.yandex.ru/clickhouse/trusty/pool/main/c/clickhouse/
(аналогично для precise, xenial)
Либо в Git репозитории - последний stable тег.

Если вы собирали ClickHouse самостоятельно, то скажите, на какой системе и с какими настройками.

Затем посмотрите на ошибки в логе. Это /var/log/clickhouse-server/clickhouse-server.err.log.

[Evgeni Makarov]

устанавливал буквально несколько дней назад

думаю, что причина в оперативной памяти на виртуальной машине (1гиг)

данные загружал не из tutorial, а из доступного real-time потока данных с частотой поступления данных примерно 20 точек в секунду

пятница, 9 декабря 2016 г., 1:19:48 UTC+3 пользователь man...@gmail.com написал: