ClickHouse memory is not being released.

[zxl-wangwang]

Company or project name

No response

Question

server version: 24.8.14.39

Use the following query statement:

SELECT
    metric,
    formatReadableSize(value)
FROM system.metrics
WHERE metric = 'MemoryTracking'

It was observed that memory usage increases periodically and does not decrease.

At this time, there are no merge tasks in the background, only a few small queries.

[ayakovlev-clickhouse]

Hey

From the graph I can see that memory growing to 90%.
Default max_server_memory_usage_to_ram_ratio = 0.9, the setting means the server is allowed to allocate up to approximately 90% of available RAM.

ClickHouse process doesn't always return pages to Linux: not necessarily, and often not immediately. Jemalloc may retain freed pages for reuse, caches may remain populated, and fragmentation may prevent whole memory regions from being returned to the OS.

On 24.8 there is no MemoryWorker to proactively purge, so OS RSS can stay high even after tracked memory drops.

To flush the memory cached by the memory allocator, you can run the SYSTEM JEMALLOC PURGE command. It should normally be a diagnostic operation, not a scheduled workaround.

The healthy expectation is that ClickHouse reuses retained memory; it does not need to reduce RSS after every query.

You can use this query to break down memory futher

SELECT metric, formatReadableSize(value) AS value
FROM system.asynchronous_metrics
WHERE metric IN ('MemoryResident','MemoryVirtual','MemoryResidentMax')
   OR metric LIKE 'jemalloc%';

Hope it answers the question.

[zxl-wangwang]

In another environment, with service version 22.8.2.11, and the same business and configuration, the memory usage is stable and does not increase periodically, so I suspect that memory reclamation may not be being performed.

[zxl-wangwang]

server version: 24.8.14.39

 SELECT
      metric,
      formatReadableSize(value) AS value
  FROM system.asynchronous_metrics
  WHERE (metric IN ('MemoryResident', 'MemoryVirtual', 'MemoryResidentMax')) OR (metric LIKE 'jemalloc%')

[ayakovlev-clickhouse]

Thanks for details.

Breakdown from your screenshot, not sure if it was collected after restart or not.

• MemoryResident (process RSS) = 1.20 GiB — this is the real physical memory ClickHouse is using right now.
• jemalloc.allocated = 630 MiB — live bytes the application actually holds.
• jemalloc.active = 733 MiB — live allocations rounded up to whole pages.
• jemalloc.metadata = 326 MiB — allocator bookkeeping (resident).
• jemalloc.resident = 1.09 GiB ≈ active (733) + metadata (326).
• jemalloc.retained = 100.45 GiB and MemoryVirtual = 110.25 GiB are virtual address space, not physical memory.

So the true footprint is ~1.2 GiB, and only ~630 MiB of that is live application data.

the memory usage is stable and does not increase periodically

This is heavily depends on workload. If there is a heavy query that uses a lot of memory, total memory will be higher.

And yes, memory reclamation on 24.8 doesn't work efficiently. There is no MemoryWorker to proactively purge used pages.