KG
Зачем вам это на ночь глядя, ейбогу
Size: a a a
2020 June 01
D
если у вас сегодня отжирает... завтра будет у нас (
D
какая версия кстати? или я проглядел?
KG
какая версия кстати? или я проглядел?
ClickHouse server version 20.4.4 revision 54434.
D
ClickHouse server version 20.4.4 revision 54434.
ну хорошо, прям завтра эт у нас точно не будет...
а вы с повторением абсолютно идентичного запроса тестировали?
может просто данные раскиданы на большее число блоков, на том запросе который фейлится
а вы с повторением абсолютно идентичного запроса тестировали?
может просто данные раскиданы на большее число блоков, на том запросе который фейлится
KG
да - запрос идентичный. Данные в базу новые не попадают
D
а можете 3-4 раза запустить с включенным трейс логом, только селект (set send_logs_level='trace', max_threads=1, max_block_size=5000). и посмотреть отожрется ли память на повторных запросах.
если да - лучше тикет завести в гитхаб...
если да - лучше тикет завести в гитхаб...
D
ну и PeakMemoryUsage посмотреть меняются ли с ходом запросов
I
привет
кто-нибудь может подсказать, почему при одинаковой выборке из двух таблиц, в одной из которых тип данных Enum8, а во второй LowCardinality(String), при одинаковом кол-ве прочитанных строк, прочитанных данных по объему больше в случае с Enum
он же по идее должен быть 1байтным, а словарь 4байтным? (уникальных значений всего 6)
Пример запроса и результатов:
SELECT field FROM table group by field order by count()
LowCardinality: 0.59 sec.| 215,835,807 rows.| 206 MB
Enum8: 0.51 sec.| 215,835,967 rows.| 1 GB
P.S. пробовал тот же трюк на других полях (тоже Enum и LowCardinality, всегда разница в объеме +- в 5 раз)
кто-нибудь может подсказать, почему при одинаковой выборке из двух таблиц, в одной из которых тип данных Enum8, а во второй LowCardinality(String), при одинаковом кол-ве прочитанных строк, прочитанных данных по объему больше в случае с Enum
он же по идее должен быть 1байтным, а словарь 4байтным? (уникальных значений всего 6)
Пример запроса и результатов:
SELECT field FROM table group by field order by count()
LowCardinality: 0.59 sec.| 215,835,807 rows.| 206 MB
Enum8: 0.51 sec.| 215,835,967 rows.| 1 GB
P.S. пробовал тот же трюк на других полях (тоже Enum и LowCardinality, всегда разница в объеме +- в 5 раз)
2020 June 02
NA
Всем привет! Подскажите по ошибке?
DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 365, e.displayText() = DB::Exception: Output of TreeExecutor is not sorted
Не нашел инфу по ней.
CH 20.4.2.9
DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 365, e.displayText() = DB::Exception: Output of TreeExecutor is not sorted
Не нашел инфу по ней.
CH 20.4.2.9
Апну проблему. 20.4.4.18. Похожая ошибка при принудительной оптимизации партиции ( Раньше такого не наблюдалось
NA
Походу надо баг заводить :(
NA
Вскрытие показало, что без FINAL оптимизация таки работает optimize table <table> partition '2020-06-01' deduplicate
S
Roman Tarasov
всем привет!
возможно кто то сталкивался
на прошлой неделе обновили мускул до 8 версии
не знаю точно ли с обновлением связано но
обнаружили что внешние словари странно теперь себя ведут
2020.05.29 04:23:19.459080 [ 53376 ] {} <Error> ExternalDictionariesLoader: Could not update external dictionary 'g_hits_1', leaving the previous version, next update is scheduled at 2020-05-29 04:23:34: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Exception: Connections to all replicas failed: database@mysql_host:3306 as user clickhouse, Stack trace (when copying this message, always include the lines below)
при неудачно попытке обновление шедулится но так и не выполняется и словари протухают
если выполнить SYSTEM RELOAD DICTIONARIES обновится и сразу фризится, повторных попыток нет
ClickHouse server version 20.3.8 revision 54433
возможно кто то сталкивался
на прошлой неделе обновили мускул до 8 версии
не знаю точно ли с обновлением связано но
обнаружили что внешние словари странно теперь себя ведут
2020.05.29 04:23:19.459080 [ 53376 ] {} <Error> ExternalDictionariesLoader: Could not update external dictionary 'g_hits_1', leaving the previous version, next update is scheduled at 2020-05-29 04:23:34: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Exception: Connections to all replicas failed: database@mysql_host:3306 as user clickhouse, Stack trace (when copying this message, always include the lines below)
при неудачно попытке обновление шедулится но так и не выполняется и словари протухают
если выполнить SYSTEM RELOAD DICTIONARIES обновится и сразу фризится, повторных попыток нет
ClickHouse server version 20.3.8 revision 54433
сделайте tcpdump -i any port 3306 -w mysql.pcap на сервере где clickhouse
и посмотрите что происходит с авторизацией
это сильно похоже на то. что MySQL8 у вас с обновленным механизмом авторизации
который возможно не реализован в clickhouse
если не трудно заведите issue на github?
и посмотрите что происходит с авторизацией
это сильно похоже на то. что MySQL8 у вас с обновленным механизмом авторизации
который возможно не реализован в clickhouse
если не трудно заведите issue на github?
ЕГ
Доброе время суток. Подскажите как принудительно завершить выполнение запроса? Делал через KILL QUERY, но вот уже как 15 минут прошло, а запрос еще висит.
S
Евгений Гаврилов
Доброе время суток. Подскажите как принудительно завершить выполнение запроса? Делал через KILL QUERY, но вот уже как 15 минут прошло, а запрос еще висит.
KILL QUERY ... WHERE ... SYNC
но KILL QUERY принудительно не завершает запрос, он только выставляет флажок который проверяется в треде исполнения запроса после того как очередной блок обработан, это может быть довольно долго ждать...
но KILL QUERY принудительно не завершает запрос, он только выставляет флажок который проверяется в треде исполнения запроса после того как очередной блок обработан, это может быть довольно долго ждать...
DG
Евгений Гаврилов
Доброе время суток. Подскажите как принудительно завершить выполнение запроса? Делал через KILL QUERY, но вот уже как 15 минут прошло, а запрос еще висит.
Можно грохнуть процесс в ОС. terminate
A
Можно грохнуть процесс в ОС. terminate
А это не завалит весь CH целиком?
A
KILL QUERY ... WHERE ... SYNC
но KILL QUERY принудительно не завершает запрос, он только выставляет флажок который проверяется в треде исполнения запроса после того как очередной блок обработан, это может быть довольно долго ждать...
но KILL QUERY принудительно не завершает запрос, он только выставляет флажок который проверяется в треде исполнения запроса после того как очередной блок обработан, это может быть довольно долго ждать...
SYNC ведь просто будет держать консоль, ничего в плане более принудительной остановки он не делает?
DG
В пятницу так сделали, были заблоченные select и DDL
DG
Всё ок, сервер не завис и не перезапустился. Убили именно процесс который под select