помимо увеличения памяти/снижения объема читаемых данных?
Code: 241. DB::Exception: Received from localhost:9000. DB::Exception: Memory limit (for query) exceeded: would use 11.18 GiB (attempt to allocate chunk of 4895686 bytes), maximum: 11.18 GiB: While executing SourceFromNativeStream.
в самом запросе используется группировка на диске (т.к. не влезает в память) через явное указание max_bytes_before_external_group_by и как я понимаю, далее падает при чтении этих данных для окончательной выдачи потребителю (исходя из того, что могу прочитать в этих исходниках — https://github.com/ClickHouse/ClickHouse/blob/master/src/Processors/Transforms/AggregatingTransform.cpp#L53 )
сколько всего памяти на машине? какое значение выставляете в max_bytes_before_external_group_by ?
max_memory_usage = 12e9, max_bytes_before_external_group_by=8e9
поставьте group_by до 6e9 или даже 4e9
1 если group by совпадает с order by таблицы то можно выполнить агрегацию через индекс, есть параметр optimize_aggregation_in_order. 2 можно уменьшать aggregation_memory_efficient_merge_threads (2/4)
пробовал) запрос достаточно трудоемкий и просто падает по памяти на чтении даже в случае чтения из одного парта (!!) при условии того, что чтение происходит в рамках primary ключа (но не ключа сортировки), т.е.: - PK - A - Ordering Key - A, B, C, D, E - Читаем по A (group by A) но с фильтрацией и аггрегацией (в том числе через groupArray) на колонках C, D, E (в том числе через HAVING в конце) точно также уменьшение max_bytes_before_external_group_by не помогает, т.к. просто увеличивает время работы запроса до того, как он упадет на нехватке памяти для SourceFromNativeStream реальным решением является семплирование через префикс для колонки A (тот же startsWith(A, '1'), например) и просто запуском для всех этих префиксов (с точки зрения прочитанных и обработанных данных мы просто оставляем некую часть). Это вариант с костылями, т.к. просто уменьшаю кол-во обрабатываемых данных в памяти. В какой-то момент кол-во данных станет больше и все снова упадет... также, соответственно, крутил разные параметры, в том числе и кол-во потоков под merge ( aggregation_memory_efficient_merge_threads ) поэтому к изначальному вопросу — можно ли как-то подсказать КХ, чтобы он использовал на финальной обработке данных ( SourceFromNativeStream ) тоже external SSD memory (как в случае external_group_by)? и второй вопрос — куда в данном случае вообще имеет смысл дальше копать (кроме как дебажить дев сборку у себя, т.к. в system.trace_log не столь ценная информация для данного кейса) спасибо
Какая версия кх? Mmap выключен?
temp каталог задаётся в конфиге
21.2.2.8 по mmap не до конца понимаю как проверить (даже гугл не дает полезной инфы типа ubuntu enable/disable mmap) но рекомендации по КХ отсюда выполненны — https://clickhouse.tech/docs/en/operations/tips/#ram
не до конца понял чем это поможет, если падает на том, что не хватает оперативной памяти
нет, это не про это. Это про баг в 21.5 / 21.4
а, я неправильно понял вопрос, я думал вы temp хотите на ssd натравить. Ответ: нет, 1/256-я часть результата group by должна помещаться в память. Там захардкожены 256 бинов. 256 это часть алгоритма и настройку сделать нельзя в принципе. 1/256 при aggregation_memory_efficient_merge_threads=1, 2/256 при aggregation_memory_efficient_merge_threads=2 сколько у вас ОЗУ и сколько уникальных элементов в group by? про optimize_aggregation_in_order, почему он не работает, ниче не понял, не продрался сквозь ваше описание.
Обсуждают сегодня