ClickHause Memory limit 'select * from table where time > 1484053200 and time < 1484082000'

[Vale2]

Это не агригированый запрос. Данные, вроде, не должны нигде накапливаться. Сервер одиночный, таблица collapsedMergeTree

(Code: 241, e.displayText() = DB::Exception: Memory limit (for query) exceeded: would use 9.31 GiB

Скачивется примерно полтора гигабайта, потом приходит exeption (Code: 241, e.displayText() = DB::Exception: Memory limit (for query) exceeded: would use 9.31 GiB (attempt to allocate chunk of 2097152 bytes), maximum: 9.31 GiB: (while reading column events.hit_sz): (while reading from part /usr/local/rle/var/clickhouse//data/default/session/20170108_20170110_1159806_1229252_12/ from mark 4096 to 4104): )$VAR1 = [
          'Code: 241, e.displayText() = DB::Exception: Memory limit (for query) exceeded: would use 9.31 GiB (attempt to allocate chunk of 2097152 bytes), maximum: 9.31 GiB: (while reading column ...): (while reading from part ... from mark 4096 to 4104): '
        ];

Таким вот образом и через curl, и через mozilla firefox и через perl LWP::UserAgent.

Сначала через LWP::UserAgent вообще почти сразу отваливался, но при сбросе http header'a client-transfer-encoding начало грузить как curl примерно.
   $ua->default_header('client-transfer-encoding' => undef);

Неужели нужно разбивать по крошечным запросам...?

[Vale2]

Посмотрел расход памяти по SHOW PROCESSLIST, похоже база кэширует слишком много данных в оперативной памяти. Может Есть какая-то возможность не читать в память, если пока буфер имеет значительный размер? как вариант рассматриваю вовсе не-нужный тут order by time c кэшированием во внешнем файле, но такой способ приведёт к излишнему копированию с диска на диск. Может дело в том, что строчка таблицы может быть большой (она содержит nested структуры), есть ли какая-нибудь возможность указать размер буфера, при котором стоит притормозить с чтением, пока буфер не очиститься? Ведь читать с диска - действительно быстрее, чем передавать в сеть.

[Vale2]

Неожиданно модификатор FINAL частично скрыл проблему, видимо потому-что выполняется в один поток. Запрос Выполняется дольше, но зато уровень потребляемой памяти колеблится в пределах 2-2.5 гб...

[Vale2]

Проблема решилась манипуляциями с параметрами max_memory_usage max_threads max_block_size , переlаваемыми рядом с телом запроса.

http://clickhause.local?max_memory_usage=1000000000&max_threads=16&max_block_size=32768&query=select+*+from+table

[man...@gmail.com]

Да, совершенно верно - всё решает параметр max_block_size.

К сожалению, размер блока задаётся в фиксированном количестве строк. Хотя строки могут быть большими.
Поэтому мы сейчас рассматриваем задачу - сделать размер блока адаптивным, чтобы о нём не нужно было беспокоиться.