The memory usage command monitors RAM consumed by ClickHouse queries or the whole server, helping prevent OOM errors and optimize performance.
Query the system.metrics
and system.asynchronous_metrics
tables. They expose real-time counters for total and per-query memory.
SELECT metric, value
FROM system.metrics
WHERE metric ILIKE '%Memory%';
The system.processes
table holds one row per live query, including the memory_usage
column.
SELECT query_id, user, formatReadableSize(memory_usage) AS mem
FROM system.processes
ORDER BY memory_usage DESC;
Enable the internal system.query_log
. It records read_rows
, read_bytes
, and memory_usage
after each query finishes.
SELECT query, formatReadableSize(memory_usage) AS mem
FROM system.query_log
WHERE event_time > now() - INTERVAL 1 HOUR
ORDER BY memory_usage DESC;
Use the max_memory_usage
setting when connecting or in each statement. ClickHouse aborts the query if the limit is exceeded.
SET max_memory_usage = 2e9; -- 2 GB
SELECT ...;
In Galaxy, open a new tab, paste the SET
statement, run it, then execute your Orders
analysis. The editor shows a warning if the limit triggers.
MemoryTracking
(allocated), RealMemoryUsage
(RSS), and UncompressedCacheBytes
(cache) give a complete picture. Monitor them with Grafana or CLI scripts.
Use SAMPLE
for large tables, avoid ORDER BY RAND()
, prefer LIMIT
early, and partition Orders
data by order_date
to prune scans.
No. memory_usage
tracks allocator bytes for the query. Cache metrics live in system.asynchronous_metrics
.
Export system.metrics
to Prometheus and configure Alertmanager rules on MemoryTracking
.
Yes. Prefix the statement with SET max_memory_usage = ...
or pass it as a client parameter.