RO
спасибо
Size: a a a
2020 June 29
A
в режиме debug все логируется в текстовом логе. И можно влючить логирование запросов в таблицу query_log
А активные подключения где-то отображаются?
DC
А активные подключения где-то отображаются?
в каком-то смысле их нет вообще в КХ, поэтому ответить на ваш вопрос нельзя, не зная вашей цели.
DC
активные запросы в system.processes
A
в каком-то смысле их нет вообще в КХ, поэтому ответить на ваш вопрос нельзя, не зная вашей цели.
Цель мониторинг начала работы пользователя и завершение его работы (завершение сессии). Я с Постгрессом работаю, в основном, там сессии не обрываются, ожидают запроса (idle)
DC
Цель мониторинг начала работы пользователя и завершение его работы (завершение сессии). Я с Постгрессом работаю, в основном, там сессии не обрываются, ожидают запроса (idle)
нету сессий в КХ, нечего мониторить
AK
Привет! Есть ли способ указать формат ответа JSON для ответа на INSERT INTO и для ошибок?
A
нету сессий в КХ, нечего мониторить
А как же установление параметров через set для сессии?
DC
А как же установление параметров через set для сессии?
ну в этом смысле нет мониторинга и нет аудита
DC
Привет! Есть ли способ указать формат ответа JSON для ответа на INSERT INTO и для ошибок?
нет
A(
Добрый вечер. А создавал кто таблицы через докер композ? Или только отдельным скриптом костылить создание таблиц в новый сервис КХ?
DT
Добрый вечер. А создавал кто таблицы через докер композ? Или только отдельным скриптом костылить создание таблиц в новый сервис КХ?
можно положить скрипты для создания в определенную папочку и тогда они будут созданы при запуске докер конта
p
Добрый вечер. А создавал кто таблицы через докер композ? Или только отдельным скриптом костылить создание таблиц в новый сервис КХ?
Подключить папку коду положить sql-файлы
volumes:
- './testsuite/entrypoint-initdb.d:/docker-entrypoint-initdb.d'
DC
Добрый вечер. А создавал кто таблицы через докер композ? Или только отдельным скриптом костылить создание таблиц в новый сервис КХ?
https://hub.docker.com/r/yandex/clickhouse-server/
scripts under /docker-entrypoint-initdb.d. After the entrypoint calls initdb it will run any *.sql files
или еще можно в metadata положить
scripts under /docker-entrypoint-initdb.d. After the entrypoint calls initdb it will run any *.sql files
или еще можно в metadata положить
A(
очень хороший способ, спасибо большое
2020 June 30
ED
да, видимо можно уменьшить index_granularity до 512 / 128, запускать запросы с max_threads=1, max_block_size=1024
отчитываюсь
так уже можно жить!
t3a.2xlarge 8/32
index granularilty 128, max_threads 1, max_block_size 1024
insert 600 rps через Buffer + 100rps этих селектов - напрягается, конечно, но тянет LA max 10
при 50 rps селектов - вообще нормально уже, LA 3-4
при более высоких index granularity похуже, но видимо больше играет max_threads/max_block_size
в чём главный минус маленького index granularity? ОЗУ жрёт больше?
так уже можно жить!
t3a.2xlarge 8/32
index granularilty 128, max_threads 1, max_block_size 1024
insert 600 rps через Buffer + 100rps этих селектов - напрягается, конечно, но тянет LA max 10
при 50 rps селектов - вообще нормально уже, LA 3-4
при более высоких index granularity похуже, но видимо больше играет max_threads/max_block_size
в чём главный минус маленького index granularity? ОЗУ жрёт больше?
S
Evgeniy Devyatykh
отчитываюсь
так уже можно жить!
t3a.2xlarge 8/32
index granularilty 128, max_threads 1, max_block_size 1024
insert 600 rps через Buffer + 100rps этих селектов - напрягается, конечно, но тянет LA max 10
при 50 rps селектов - вообще нормально уже, LA 3-4
при более высоких index granularity похуже, но видимо больше играет max_threads/max_block_size
в чём главный минус маленького index granularity? ОЗУ жрёт больше?
так уже можно жить!
t3a.2xlarge 8/32
index granularilty 128, max_threads 1, max_block_size 1024
insert 600 rps через Buffer + 100rps этих селектов - напрягается, конечно, но тянет LA max 10
при 50 rps селектов - вообще нормально уже, LA 3-4
при более высоких index granularity похуже, но видимо больше играет max_threads/max_block_size
в чём главный минус маленького index granularity? ОЗУ жрёт больше?
.mrk файлы больше по размеру
соответсвенно mark_cache вымывается чаще
и lookup \ filter по primary key медленее в среднем
соответсвенно mark_cache вымывается чаще
и lookup \ filter по primary key медленее в среднем
VM
А в чём минусы большой гранулярности?
BB
А в чём минусы большой гранулярности?
Он вам в память может не поместиться , наверное , самое существенное .
S
А в чём минусы большой гранулярности?
ну дык это, если PK сильно кардинальный, а гранулярность 8192 по умолчанию
это значит что записывается в .mrk только каждая 8192 значение PK (в смысле значение всех ПОЛЕЙ в PK)
и соответсвенно чаще будет сканироваться сама колонка а не .mrk файл
это значит что записывается в .mrk только каждая 8192 значение PK (в смысле значение всех ПОЛЕЙ в PK)
и соответсвенно чаще будет сканироваться сама колонка а не .mrk файл