Clickhouse: Не освобождается память при исключениях во время запроса

[se-teryoshkin]

Мой случай очень похож на данный:
https://github.com/ClickHouse/clickhouse-go/issues/93

Если в ходе выполнения запроса происходит ошибка, то память, выделенная запросу, не освобождается.

О таблице.
Схема создания:

CREATE TABLE vk.posts
(
    ctime DateTime,
    date DateTime,
    post_id Int64,
    from_id Int64,
    owner_id Int64,
    comments_count Int32,
    likes_count Int32,
    reposts_count Int32,
    views_count UInt32,
    text Nullable(String),
    signed_by Nullable(Int64),
    post_type String,
    reposted_from_owner_id Nullable(Int64),
    reposted_from_post_id Nullable(Int64),
    geo UInt8,
    geo_lat Nullable(Float64),
    geo_lon Nullable(Float64),
    geo_hash Nullable(String),
    photo_attachments Nested (
        owner_id Int64,
        photo_id Int64,
        size Int64,
        url String,
        geo_lat Nullable(Float64),
        geo_lon Nullable(Float64),
        geo_hash Nullable(String)
    ),
    video_attachments Nested (
        owner_id Int64,
        video_id Int64,
        views UInt32
    ),
    audio_attachments Nested (
        owner_id Int64,
        audio_id String,
        artist String,
        title String
    ),
    doc_attachments Nested (
        owner_id Int64,
        doc_id Int64,
        title String,
        size Int64,
        url String,
        type Nullable(Int16)
    ),
    link_attachments Nested (
        title String,
        url String
    ),
    page_attachments Nested (
        group_id Int64,
        page_id Int64
    ),
    sticker_attachments Nested (
        sticker_id Int64
    ),
    photos_attachments_count Int32,
    videos_attachments_count Int32,
    audios_attachments_count Int32,
    docs_attachments_count Int32,
    links_attachments_count Int32,
    pages_attachments_count Int32,
    stickers_attachments_count Int32
)
ENGINE = ReplacingMergeTree(ctime)
PARTITION BY toYear(date)
PRIMARY KEY (owner_id, post_id)
ORDER BY (owner_id, post_id)
SETTINGS
    index_granularity=4096;

Характеристики лежащих в ней данных:

Настройки используются дефолтные, однако изменен параметр max_memory_usage увеличенный до 64.0 Гб.

Пример запроса, который падает с исключением и само выбрасываемое исключение:

Также прикладываю скриншоты из htop до выполнения запроса, после выполнения запроса, и спустя ещё 30 минут после исключения. Всё это время память остаётся занятой.
До

После

Спустя ещё 30 минут

Помимо этого, КХ отправлял статистику в Graphite. На скриншоте ниже чётко видно время начала запроса и его окончания. Однако, почему-то есть рассогласованность. Судя по графикам, КХ освободил память (хотя это не так).

Processlist КХ пустой:

Прикладываю фрагмент лога, записанный во время выполнения запроса.
query_log.txt

[den-crane]

КХ может не освобождать и после успешного запроса (кеширование в аллокаторе).

1. наблюдается ли рост если этот запрос с ошибкой повторить многократно?
2. наблюдается ли рост если этот запрос без ошибки (модифицированный или с другими max_memory_usage) повторить многократно?

[se-teryoshkin]

КХ может не освобождать и после успешного запроса (кеширование в аллокаторе).

1. наблюдается ли рост если этот запрос с ошибкой повторить многократно?
2. наблюдается ли рост если этот запрос без ошибки (модифицированный или с другими max_memory_usage) повторить многократно?

В обоих случаях рост не наблюдается.
Возможно ли как-то влиять с помощью настроек на кеширование в аллокаторе?

[den-crane]

Возможно ли как-то влиять с помощью настроек на кеширование в аллокаторе?

Какой в этом смысл? Да КХ не отдает память, это сделано специально чтобы не тратить время на аллокацию.

[se-teryoshkin]

Какой в этом смысл? Да КХ не отдает память, это сделано специально чтобы не тратить время на аллокацию.

Из-за этого за ним иногда приходит oom-killer

[den-crane]

Какой в этом смысл? Да КХ не отдает память, это сделано специально чтобы не тратить время на аллокацию.

Из-за этого за ним иногда приходит oom-killer

Не вижу связи. oom-killer приходит потому что КХ аллоцирует память, а не потому что он не деаллоцирует.
Лимитируйте максимальное потребление в районе 75% (60%) от имеющегося ОЗУ, с помощью параметров max_memory_usage/max_memory_usage_for_user/max_memory_usage_for_all_queries

Чтобы groupby/orderby выполнялись при лимитированном размере, установите max_bytes_before_external_sort/max_bytes_before_external_group_by в половину от max_memory_usage