D
это не объясняет почему памяти не хватает через несколько итераций
У меня обычно мердж кикается вроде сам начинается после 4 инсерта в эту же таблицу ) может он начинает кушать память
Size: a a a
2020 June 01
KG
И первая таблица никак не связана со второй?
первая и вторая таблица структурно одинаковы кроме поля time которое поменло тип. Между собой они не связаны никак
D
первая и вторая таблица структурно одинаковы кроме поля time которое поменло тип. Между собой они не связаны никак
А вы можете после каждой вставки смотреть в system.merges, и если идет мердж чуток подождать? В целях эксперимента
DC
Подскажите еще пожалуйста, что может быть не так с "
Received exception from server (version 20.1.3):
Code: 306. DB::Exception: Received from 127.0.0.1:9000. DB::Exception: Stack size too large. Stack address: 0x7f4d3dfff000, frame address: 0x7f4d3e3fefe0, stack size: 4194336, maximum stack size: 8388608." запрос "SELECT * FROM table_name LIMIT 1"?table_name -- это вью которое читает само себя?
B
нет, обычная таблица с данными
B
а какая у Вас мысль?
DC
а какая у Вас мысль?
create view x(A Int64) as select 1 from x;
select * from x limit 1
DB::Exception: Stack size too large. Stack address: 0x7ff9da37a000, frame address: 0x7ff9da777fc0, stack size: 4202560, maximum stack size: 8388608.
select * from x limit 1
DB::Exception: Stack size too large. Stack address: 0x7ff9da37a000, frame address: 0x7ff9da777fc0, stack size: 4202560, maximum stack size: 8388608.
DM
Получилось подключиться?
KG
это не объясняет почему памяти не хватает через несколько итераций
Если оставляю только селекты без втавки - тоже потихоньку выедает память и падает. Медленнее, но итог один
DC
Если оставляю только селекты без втавки - тоже потихоньку выедает память и падает. Медленнее, но итог один
после каждого селект
select * from system.asynchronous_metrics where metric like '%MarkCacheBytes%'
select * from system.asynchronous_metrics where metric like '%MarkCacheBytes%'
KG
после каждого селект
select * from system.asynchronous_metrics where metric like '%MarkCacheBytes%'
select * from system.asynchronous_metrics where metric like '%MarkCacheBytes%'
MarkCacheBytes 2783713920 и не меняется
OA
Получилось подключиться?
Да
OA
Спасибо за помощь. Разобрался.
Это дефект на стороне DataGrip.
Не смотря на то, что в настройках соединения SSL включен, сертификат отдан и включена его проверка, при коннекте это не учитывалось.
В строке коннекта насильно добавил ssl=true и блок с SSL начал работать.
Отправлю ребятам из JB ишью в их трекер 🙂
Оставлю этот пост здесь. Вдруг кому пригодится 🙂
#datagrip #ssl #yandex
Это дефект на стороне DataGrip.
Не смотря на то, что в настройках соединения SSL включен, сертификат отдан и включена его проверка, при коннекте это не учитывалось.
В строке коннекта насильно добавил ssl=true и блок с SSL начал работать.
Отправлю ребятам из JB ишью в их трекер 🙂
Оставлю этот пост здесь. Вдруг кому пригодится 🙂
#datagrip #ssl #yandex
Тут описал
DM
Тут описал
спасибо
D
Если оставляю только селекты без втавки - тоже потихоньку выедает память и падает. Медленнее, но итог один
у вас селект всегда с одинаковым количеством строк?
можете поставить
——
SELECT
time,
...
FROM table1
where time=XXX
LIMIT 6000
—-
и посмотреть выедается ли память ?
можете поставить
——
SELECT
time,
...
FROM table1
where time=XXX
LIMIT 6000
—-
и посмотреть выедается ли память ?
KG
у вас селект всегда с одинаковым количеством строк?
можете поставить
——
SELECT
time,
...
FROM table1
where time=XXX
LIMIT 6000
—-
и посмотреть выедается ли память ?
можете поставить
——
SELECT
time,
...
FROM table1
where time=XXX
LIMIT 6000
—-
и посмотреть выедается ли память ?
Да у меня селект с одинаковым количеством строк, да там лимит написан. Да - память отжирается
Д
Да у меня селект с одинаковым количеством строк, да там лимит написан. Да - память отжирается
А можно код посмотреть?
KG
Код селекта?
Д
KG
Да такой же как выше, только вместо многоточия от 100 до 150 полей